Re: issue-#156 adding Coroutines to BlackBox
Posted: Mon Apr 24, 2017 6:35 am
I am now asking for a vote about including the coroutine support as in
issue branch issue-#156.
For the diffs see ... oops "An error occurred when trying to access the repository: Cannot allocate memory - 'git' --version --no-color"
Chairman, feel free to split the vote into any number of sub votes if you think
it would help finding a decision.
Let me summarize the reason and rationale for the proposal.
The short form:
If you don't know what a coroutine is, I can only ask you to trust me.
This is a starting point for a new feature that fits well with the BlackBox design.
It can be refined later if experience shows new requirements or problems.
Without starting it, we will never get experience for refining it.
There are no incompatibilities whatsoever.
This is a pure add-on that is not activated if not used.
Kernel size is increased from 31001 to 32902 bytes, i.e. by 1901 bytes.
The long form:
There seems to be a need by the community for supporting coroutines in
BlackBox as can be seen by the existence of the CPC package named Co_.
I can only confirm the need for coroutine support by my own experience.
It is certainly not used every day but sometimes it can be very helpful, for example
when dealing with long running background tasks or with discrete event simulation.
It is not possible to add coroutine support without Kernel modifications.
Therefore Kernel support for coroutines has been added.
Coroutine support has been added such that it cannot introduce any instabilities
because the new code is only activated when coroutines are really used.
This trades a small amount of code replication for guaranteed stability.
Coroutine support is encapsulated in Kernel because Kernel maintains the core
runtime data structures including the heap, the main stack, the trap handling, the stack overflow detection,
the garbage collection etc. and coroutines are part of that. Any split would break that abstraction
and introduce more complications than simplifications. BlackBox has been designed by ominc
from the beginning as a portable system with support for Windows and MacOS.
Some base modules have been split and implemented in a separate Host module.
Kernel is not among them. I trust the design of ominc in this respect and don't see any
chance and need to 'improve' this.
(personal estimation: with the amount of time spent into looking at alternative approaches,
coroutines could have been ported to 3 platforms including maintenance for 10 years.)
The Kernel's coroutine support makes it possible to implement the Co_ package
without crashing BlackBox occasionally. There have been doubts that this would be possible
but it has been shown that it works by simply replacing the WinApi fiber calls by
the corresponding Kernel calls 1:1.
The Co_ package is designed with specific kinds of applications in mind. It is not
a general purpose coroutine library. Therefore a general purpose module named 'Coroutines'
has been added. In addition to basic general purpose coroutines it supports
two special coroutine patterns named Task and Iterator. These are common patterns that
can appear in many applications. They are special in the sense that they have
additional methods (Transfer wrappers) with checked pre- and post conditions that
restrict their usage to the intended purpose.
Further application specific patterns can be implemented on top of Coroutines.
It would for example be possible to create a library specifically
targeted at discrete event simulation or similar.
ObxCoroutines has been added for showing by example how plain coroutines,
Tasks and Iterators can be used.
- Josef
issue branch issue-#156.
For the diffs see ... oops "An error occurred when trying to access the repository: Cannot allocate memory - 'git' --version --no-color"
Chairman, feel free to split the vote into any number of sub votes if you think
it would help finding a decision.
Let me summarize the reason and rationale for the proposal.
The short form:
If you don't know what a coroutine is, I can only ask you to trust me.
This is a starting point for a new feature that fits well with the BlackBox design.
It can be refined later if experience shows new requirements or problems.
Without starting it, we will never get experience for refining it.
There are no incompatibilities whatsoever.
This is a pure add-on that is not activated if not used.
Kernel size is increased from 31001 to 32902 bytes, i.e. by 1901 bytes.
The long form:
There seems to be a need by the community for supporting coroutines in
BlackBox as can be seen by the existence of the CPC package named Co_.
I can only confirm the need for coroutine support by my own experience.
It is certainly not used every day but sometimes it can be very helpful, for example
when dealing with long running background tasks or with discrete event simulation.
It is not possible to add coroutine support without Kernel modifications.
Therefore Kernel support for coroutines has been added.
Coroutine support has been added such that it cannot introduce any instabilities
because the new code is only activated when coroutines are really used.
This trades a small amount of code replication for guaranteed stability.
Coroutine support is encapsulated in Kernel because Kernel maintains the core
runtime data structures including the heap, the main stack, the trap handling, the stack overflow detection,
the garbage collection etc. and coroutines are part of that. Any split would break that abstraction
and introduce more complications than simplifications. BlackBox has been designed by ominc
from the beginning as a portable system with support for Windows and MacOS.
Some base modules have been split and implemented in a separate Host module.
Kernel is not among them. I trust the design of ominc in this respect and don't see any
chance and need to 'improve' this.
(personal estimation: with the amount of time spent into looking at alternative approaches,
coroutines could have been ported to 3 platforms including maintenance for 10 years.)
The Kernel's coroutine support makes it possible to implement the Co_ package
without crashing BlackBox occasionally. There have been doubts that this would be possible
but it has been shown that it works by simply replacing the WinApi fiber calls by
the corresponding Kernel calls 1:1.
The Co_ package is designed with specific kinds of applications in mind. It is not
a general purpose coroutine library. Therefore a general purpose module named 'Coroutines'
has been added. In addition to basic general purpose coroutines it supports
two special coroutine patterns named Task and Iterator. These are common patterns that
can appear in many applications. They are special in the sense that they have
additional methods (Transfer wrappers) with checked pre- and post conditions that
restrict their usage to the intended purpose.
Further application specific patterns can be implemented on top of Coroutines.
It would for example be possible to create a library specifically
targeted at discrete event simulation or similar.
ObxCoroutines has been added for showing by example how plain coroutines,
Tasks and Iterators can be used.
- Josef