issue-#156 adding Coroutines to BlackBox

[luowy]

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.

[Josef Templ]

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.

Can I take this reply as supporting the idea of adding Coroutines in principle?

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/projects/blackbox/repository/diff?utf8=%E2%9C%93&rev=dffbe8bf2b8e86e819e8162dbeeb8c407cd57b0c&rev_to=642b6e3f02d3145bb12bd56bf2a7d8a75711dbea.

- Josef

[Ivan Denisov]

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.

Can I take this reply as supporting the idea of adding Coroutines in principle?

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.
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 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.

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.

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...

co_exp_not_working.txt

(9.58 KiB) Downloaded 98 times

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]

Thanks for the comments.

I will be away from the Internet until Monday.

- Josef

[Josef Templ]

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.

Thanks. I also see this version as a starting point that should give us some feedback.
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/projects/blackbox/repository/diff?utf8=%E2%9C%93&rev=94253d4557fc1daf3128e751b0b3744f20db86d5&rev_to=72684cd0c81ca74f54f75b9c0738e15891acbdb7.

The latest build is http://blackboxframework.org/unstable/issue-%23156/blackbox-1.7.1-a1.826.zip.

- Josef

[Ivan Denisov]

Josef, I forgot to mention you attention on the indentation problem. In all BlackBox modules there are some traditional formatting.

[Josef Templ]

indentation fixed. Thanks for the hint.

- josef

[Robert]

The stack grows as needed until a system defined limit, which is about 2MB by default.

Where is this limit defined, and can it be changed by a user?

[Josef Templ]

The stack grows as needed until a system defined limit, which is about 2MB by default.

Where is this limit defined, and can it be changed by a user?

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.
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

[cfbsoftware]

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

DevLinker.WriteHeader contains the following statements:

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 *)