small improvement in Kernel.AddCoroutine:
stackBase reset to 0.
This enables one to reuse the object for several coroutines.
See diffs at
https://redmine.blackboxframework.org/p ... 635894ffe6.
The WinApi calls have been moved to Kernel originally in order to do Ivan a favor.
In the meantime it turned out to be a good move. Why?
Because it is easy this way to guarantee consistency.
If half of the coroutine support is done in the Kernel and the other half is done outside,
it is easily possible to tell the Kernel to switch to coroutine A and via the other half
to switch to coroutine B, creating occasional system crashes in the garbage collector, for example.
By keeping them together this consistency is guaranteed by design.
It also gives the coroutine support routines more flexibility in their implementation
because all aspects are handled at one place.
There is also no runtime overhead by that organization.
The exchangeability need is hard to follow for me.
If there is a much better implementation available it should be used as the default implementation.
Does anybody need multiple implementations at the same time?
I doubt it (and it may create problems if they are mixed at runtime).
The Co_ package has been transformed to use the Kernel's coroutine services now.
There were no surprises, as I expected. A straightforward 1:1 replacement
of WinApi fiber calls by the corresponding Kernel coroutine procedures.
The only surprise was that the Co_ author previously thought that it is not possible.
- Josef