Dmitry Dagaev wrote:There was no limitation of Transfer to main only. Nested coroutines allways were supported by Co_. Naturally, directed coroutine must return to the caller. The caller can be main or other coroutine. The same FILO discipline, as subroutine call and return.
Dmitry, you have modified my nested iterator example.
As far as I see, it is not possible to implement it with Co_.
I have tried it without success.
Please try it without cheating .
It was never the goal of the Coroutines module to compete with Co_, in particular
not with respect to its data flow programming support.
This is what I mean with special purpose versus general purpose.
There could also be a discrete event simulation framework somewhere
as CPC package but I would not include it in the standard distribution.
This does not mean that one is better than the other. It's just different.
Dmitry Dagaev wrote:There was no limitation of Transfer to main only. Nested coroutines allways were supported by Co_. Naturally, directed coroutine must return to the caller. The caller can be main or other coroutine. The same FILO discipline, as subroutine call and return.
I afraid that it was my wrong interpretation for Josef. However I am happy that this leads to dialog of you and Josef about this question. FILO is good, I believe.
The dialog is much better in this case. Otherwise (for example) center's Coroutines Sleep(0) implementation can never exceed 6% CPU. You have mentioned the problem, I've provided time comparisons.
By the way, I have 2 latest builts: 849 mentioned above and 852 http://blackboxframework.org/unstable/i ... a1.852.zip yours. Are you planning to upgrade your version to Josef's last changes (Kernel.BeginCoroutines, Kernel.EndCoroutines)? Shall I implement new Co_ for your HostCoroutines also?
The example I am referring to is the nested iterator example viewtopic.php?f=54&t=164&start=70#p1023. It has been posted a few messages earlier in this thread.
It is not in the ObxCoroutines module and I never claimed that.
There is currently a problem with the build engine (or Edis host) that Ivan is working on.
The latest build 856 for branch issue-#156 failed. Sorry for any inconveniences.
If you want to do any tests in the meantime you could download the source code
of Coroutines directly from https://github.com/BlackBoxCenter/black ... utines.odc.
Your example, please:
Main creates A
A creates B
A transfers to B
B yields to A
A transfers to B
B yields to A
A transfers to B
B yields to A
A transfers to B
B yields to A
A transfers to B
B yields to A
A transfers to B
B yields to A
A yields to Main
I just removed (*ASSERT(current = NIL, MUST_BE_PRIMARY);*) protection in Co_Routines. It is mandatory for BlackBox without Kernel Coroutines support for prohibition to allocate inside coroutine. It is not needed if Kernel's GC is available of coroutine's local stacks. I hope I can trust Center's new Kernel Coroutines support would be also included in further BlackBox releases.
Dmitry Dagaev wrote:By the way, I have 2 latest builts: 849 mentioned above and 852 http://blackboxframework.org/unstable/i ... a1.852.zip yours. Are you planning to upgrade your version to Josef's last changes (Kernel.BeginCoroutines, Kernel.EndCoroutines)? Shall I implement new Co_ for your HostCoroutines also?
IMHO, extra work is not required for now. Let's wait a bit. If Center will force to use Josef's Kernel embedded implementation ignoring all my claims for the preliminary voting I have to start parallel project with the focus to cross-platform solutions. Josef said earlier that he does not see the reasons for cross-platform capabilities for BlackBox and this leaves an imprint for all solutions he is developing. Because his professionalism is valuable and is not compensating by the discussion and voting process that shifts the focus of Center activity to Windows. So the goals of the Center for multiple platforms can not be reached with such team. I do not see perspectives.
luowy wrote:if we can implement the coroutine use stackless tech, maybe we can make
Josef Templ wrote:an optimization for special cases offered by some languages but it needs a language change and heavy optimizations in the compiler
I've written before viewtopic.php?f=54&t=164&start=40#p992 that Kernel support for stacks&traps must be separated from Coroutines implementation. HostCoroutines subsystem gives anybody an opportunity to reimplement coroutines in custom way.
By the way the 2-nd BlackBox coroutines implementation by Ilya Ermakov (not published) uses transfer implementation by register switching:
luowy wrote:our framework can provide two std scheduler
Co_SchedTasks can be reimplemented in standart BlackBox way for your own needs.
Co.scheduler and Co.stdScheduler are factories like Files.dir, Files.stdDir.
luowy wrote:certainly,coroutine must has "state" field;
then user's can use "resume","yeild","sleep"
Co_ is based on Carrier-Link-Rider model: Scheduler-Dispatcher-Coroutine. Scheduler holds state, the basic states are:
ST_READY* = 1; ST_LOCKED* = 2; ST_FINISHED* = 3; ST_SUSPENDED* = 4;
ST_NEXTREADY* = 5; ST_SLEEP* = 6;
Dispatcher with states can be reimplemented for Custom needs like Scheduler.
Co_ObxShakesPeare demonstrates Finite State Machine example:
PROCEDURE Next (r, rnext: Player);
BEGIN
r.Suspend;
rnext.Resume;
rnext.SchedSleep(1000);
END Next;
PROCEDURE (r: Desdemona) Do ;
BEGIN
Say(r, "Your honour is most welcome.");
Next(r, othello); Co.Yield;
Say(r, "My lord?");
Next(r, othello); Co.Yield;
Say(r, "I will, my lord");
Co.Stop
END Do;
Next suspends and resumes execution state and schedulers Co_Routine to wakeup after 1000 ms.