issue-#156 adding Coroutines to BlackBox

[Josef Templ]

Your RemoveCoroutine version has a different behaviour...

I just realize that your version is inconsistent... it can remove StackInfo from the list and then does not remove Fiber. Why did you do it this way?

To speed up garbage collection.

- Josef

[Ivan Denisov]

Your RemoveCoroutine version has a different behaviour...

I just realize that your version is inconsistent... it can remove StackInfo from the list and then does not remove Fiber. Why did you do it this way?

To speed up garbage collection.

This procedure is executing without interrupts. Why you think, that this is speeding up garbage collection?

Anyway you said, that the main benefit of this realization is the consistency, but you sacrificed it for possible speeding up of garbage collection.

Also I can not understand why mu CPU is 7% load with Primes example... Why it is not 100% load? Is it possible to add simple balancer?
Should the background task effectively use the time with Sleep(0) or not?

[Josef Templ]

This procedure is executing without interrupts. Why you think, that this is speeding up garbage collection?

Anyway you said, that the main benefit of this realization is the consistency, but you sacrificed it for possible speeding up of garbage collection.

It allows to remove a coroutine from the list of coroutines as early as possible, i.e. when the coroutine returns (or traps).
At that time the coroutine is still running but the stack is no longer needed for garbage collection.
A coroutine stack may lead to a complete heap scan, which is a very expensive operation in the garbage collector.
This has nothing to do with interrupts. The garbage collector may be called later.

Also I can not understand why mu CPU is 7% load with Primes example... Why it is not 100% load? Is it possible to add simple balancer?
Should the background task effectively use the time with Sleep(0) or not?

A Task transfers to main periodically in order not to block the user interface.
The Windows idle period then limits the CPU utilization, I guess.
If you run in Server Mode it should be higher. Also if you start more than one task.
In any case, there is only one CPU being used. So if you have a multicore system
you must look at the CPU utilization per CPU.

There is only a very simple mechanism behind Task. But if you want to
add more features it gets complicated quickly.
And one of the core problems is the precision of the Windows tick count, which is very
coarse grained. In addition, it will never behave like a multi-threaded system
using a preemptive scheduler. There are limits and trade-offs, even in Co_.
The current implementation is the simplest that delivers useful results, I believe.
Anything beyond that is left to applications (or future refinements).

- Josef

[Ivan Denisov]

Thank you for the answers.

Let's make the voting and choose the composition. All the arguments discussed. IMHO, we should not waste our time...

I am suggesting some draft for the voting message.

1. Realization in the Kernel
pluses:
- more consistent version (nobody can switch stack without switching coroutine)
minuses:
- less flexible (you can choose realization only with Kernel relinking)
- more difficult to port and support (stack manipulations mixed with OS specific calls)

2. Realization in the HostCoroutines utilizing new Kernel stacks manipulation abilities
pluses:
- easier to develop and support;
- no extra WinApi calls in System;
minuses:
- less consistent version (some user has ability to switch stack without switching coroutine)
- Coroutines can not be unloaded "on the fly"

[Josef Templ]

With the last update I have added support for multiple co-existing client modules.
Now both Coroutines and Co_Routines can be loaded and used within BlackBox.
The latest build is http://blackboxframework.org/unstable/i ... a1.849.zip.

I have looked at Ivan's solution and found the following problems:
- automatic import of Coroutines and HostCoroutines in HostDialog: this saves a few bytes in the Kernel but adds two modules to the running system even if they are not used. This is much more overhead. In addition this switches on coroutine support, which I tried to avoid (for guaranteed unchanged behavior) as long as coroutines are not used.
- If the import of HostCoroutines is not done automatically, you must import both Coroutines and HostCoroutines in any client module such as ObxCoroutines.
- redundant type Impl in the interface of Coroutines
- undocumented Host interface as usual for Host modules
- parts of the internal logic of the Kernel's coroutine support procedures are replicated in HostCoroutines
in order to achieve a similar (not even the same) behavior.
Whenever there is a change there, it must be done at several places. This is what I mean by (in)consistency.
The compiler does not flag such places and it is very easy to overlook something.

Overall, for me this is an enormous overkill for avoiding a few lines in Kernel.

- Josef

[cfbsoftware]

I have looked at Ivan's solution and found the following problems:

OK. Now, what do you consider to be the advantages of his solution over yours?

[Ivan Denisov]

After preliminary voting I have to adopt last changes proposed by Josef. Now I do not want to waste time if Center will choose Josef's composition.

[Ivan Denisov]

- undocumented Host interface as usual for Host modules

HostCoroutines has no interface so there is nothing can be documented.

I have looked at Ivan's solution and found the following problems:
- automatic import of Coroutines and HostCoroutines in HostDialog: this saves a few bytes in the Kernel but adds two modules to the running system even if they are not used. This is much more overhead. In addition this switches on coroutine support, which I tried to avoid (for guaranteed unchanged behavior) as long as coroutines are not used.
- If the import of HostCoroutines is not done automatically, you must import both Coroutines and HostCoroutines in any client module such as ObxCoroutines.

I solved this problems and now HostCoroutines loads directly after the import of Coroutines. So if some user do not need Coroutines they will not be loaded.
Unchanged behavior is guaranteed.
http://blackboxframework.org/unstable/i ... a1.852.zip

Now users can unload Coroutines "on the fly". So there is minus one minus for my composition. Also I updated the formulation of few points according Josef's comments above.

1. Realization in the Kernel
pluses:
- if there is a change in coroutines realization (stack or fibers) logic, it can be done at one Kernel module (more consistent version)
minuses:
- less flexible (you can choose realization only with Kernel relinking)
- more difficult to port and support (stack manipulations mixed with OS specific calls)

2. Realization in the HostCoroutines utilizing new Kernel stacks manipulation abilities
pluses:
- easier to develop and support;
- no extra WinApi calls in System;
minuses:
- if there is a change in coroutines realization (stack or fibers) logic it should be fixed in Kernel or HostCoroutines module appropriately (less consistent version).

I even do not think that last minus is really minus. This makes support even easier.

[Josef Templ]

I have looked at Ivan's solution and found the following problems:

OK. Now, what do you consider to be the advantages of his solution over yours?

The answer is in the last sentence of my previous posting:
> Overall, for me this is an enormous overkill for avoiding a few lines in Kernel.

It avoids a few lines in Kernel. Those lines that handle the WinApi fiber calls.

In addition, it allows one to exchange the fiber implementation outside of Kernel,
i.e. inside HostCoroutines.
However, it remains an open question who needs this if the
Kernel's implementation is well done. For any experiments it
is always possible to modify the Kernel and link a new exe. it is just a mouse click
and it is not something that is done every day.
Also, due to the simpler structure (no callbacks, no hooks) for me it is effectively simpler
to modify the Kernel directly and it gives you full control over any logic that may be involved
between the Kernel support and the outside support.
Under Windows, at least, I would also expect subtle problems with stack overflow
detection and trap handling if the coroutine implementation is switched to something else
than Windows fibers.

- Josef

[Josef Templ]

The latest build delivers a CPU utilization of close to 100% for both server mode and normal mode.
The Primes example benefits from this change.

The very latest update also removes the IMPORT SYSTEM from Coroutines.

- Josef