issue-#156 adding Coroutines to BlackBox
Re: issue-#156 adding Coroutines to BlackBox
only a new golang user ,but I known the go-routine is multi-threads switch, more complex than our single thread one.
and I think the single thread coroutine is good enough for BB.
and I think the single thread coroutine is good enough for BB.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#156 adding Coroutines to BlackBox
Can I take this reply as supporting the idea of adding Coroutines in principle?Ivan Denisov wrote:I analyzed the proposed solution. It is not hard to split this well. I will try to work this evening on this and suggest some version with a same interface.
Regarding the WinApi calls. It is easy to move them out of Coroutines, of course.
It only makes the Kernel a few lines larger but it is almost nothing.
See the latest diffs at https://redmine.blackboxframework.org/p ... a75711dbea.
- Josef
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: issue-#156 adding Coroutines to BlackBox
I have mixed fillings. In one hand this can be the step to some interface to parallel computing in future. Coroutines have no such ability, but anyway this is some step further.Josef Templ wrote:Can I take this reply as supporting the idea of adding Coroutines in principle?Ivan Denisov wrote:I analyzed the proposed solution. It is not hard to split this well. I will try to work this evening on this and suggest some version with a same interface.
In another hand, you are suggesting to make our complicated framework more complicated. It means that it will be harder to support it, port to another platforms etc.
Between coroutines and portability I will choose portability and simplicity for my self. However I understand that for many developers this choice will be different.
Regarding to the new version. It is acceptable in terms of general BlackBox design. This is good work. Previous version has benefit that there were no WinApi manipulations in Kernel, only some stacks manipulations. In future the kernel it self should be split to Host part and logical parts. However that is another issue.Josef Templ wrote:Regarding the WinApi calls. It is easy to move them out of Coroutines, of course.
It only makes the Kernel a few lines larger but it is almost nothing.
I am attaching my attempt of splitting HostPart from your previous version of module. It is not working and I do not have ability to continue. The one experience I got is that factory pattern is not compatible with inheritance pattern... The best option from my point of view would be that the main logic is located in Coroutines, memory logic (stack, traps etc.) is located in Kernel and Windows fibers logic is located in HostCoroutines.
I will vote for this issue in the current state anyway.
I think that in spite of many debatable points we can include this feature to 1.7.1 to have some experience and feedbacks.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#156 adding Coroutines to BlackBox
Thanks for the comments.
I will be away from the Internet until Monday.
- Josef
I will be away from the Internet until Monday.
- Josef
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#156 adding Coroutines to BlackBox
Thanks. I also see this version as a starting point that should give us some feedback.Ivan Denisov wrote: I will vote for this issue in the current state anyway.
I think that in spite of many debatable points we can include this feature to 1.7.1 to have some experience and feedbacks.
I would not see it as dramatic if coroutines are not supported by a BlackBox port.
One advantage of having it in the standard distribution is that there is a common
API for any port that tries to support coroutines in the future.
(In general, BTW, I would expect that coroutines are easy to port to other platforms
because they are very simple indeed. If not supported by the platform itself,
they can always be implemented with a couple of code procedures
that switch the program counter and stack pointer and save/restore some registers.
The only subtle point is the detection of stack overflows, which needs an inaccessible
'dummy' page at the stack's end.)
I have added a simple ObxCoroutines example module (similar to TestCoroutines)
and I have now included the Coroutines module in the Build-Tool.
I have overlooked this before.
For the diffs see https://redmine.blackboxframework.org/p ... 5891acbdb7.
The latest build is http://blackboxframework.org/unstable/i ... a1.826.zip.
- Josef
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: issue-#156 adding Coroutines to BlackBox
Josef, I forgot to mention you attention on the indentation problem. In all BlackBox modules there are some traditional formatting.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#156 adding Coroutines to BlackBox
indentation fixed. Thanks for the hint.
- josef
- josef
Re: issue-#156 adding Coroutines to BlackBox
Where is this limit defined, and can it be changed by a user?The stack grows as needed until a system defined limit, which is about 2MB by default.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#156 adding Coroutines to BlackBox
It is the same limit as for the main BlackBox application stack.Robert wrote:Where is this limit defined, and can it be changed by a user?The stack grows as needed until a system defined limit, which is about 2MB by default.
As far as I know this is encoded somewhere in an application's
exe file (or it can be specified there if the default is not sufficient?)
but I don't know the details.
So far BlackBox has no configuration option for the stack size.
The number "2MB" resulted from tests.
It should be noted that Windows does not allocate the full 2MB per stack in advance
but only makes a reservation for a contiguous 2MB address space. By means of using
the memory management unit (MMU) stack pages are allocated on demand.
- Josef
-
- Posts: 204
- Joined: Wed Sep 18, 2013 10:06 pm
- Contact:
Re: issue-#156 adding Coroutines to BlackBox
DevLinker.WriteHeader contains the following statements:Josef Templ wrote: It is the same limit as for the main BlackBox application stack.
As far as I know this is encoded somewhere in an application's
exe file (or it can be specified there if the default is not sufficient?)
but I don't know the details.
- Josef
Code: Select all
Write4(200000H); (* stack reserve size *)
Write4(10000H); (* stack commit size *)
IF isDll THEN
Write4(00100000H); (* heap reserve size *)
ELSE
Write4(00400000H); (* heap reserve size *)
END;
Write4(10000H); (* heap commit size *)