Page 9 of 11

Re: issue-#156 adding Coroutines to BlackBox

Posted: Wed Apr 26, 2017 11:19 am
by Josef Templ
luowy wrote:Josef,
1, shared stack coroutine is more valuable than independent stack one;
2,sperate scheduler from coroutine is needed,
Q: where the trap handle code for coroutine? what happen when coroutine traped?
ad 1: I don't know what that is. Can you explain?

ad 2: Coroutines by definition don't need a scheduler but are scheduled explicitly by calling Transfer.
Depending on the application, something like a scheduler, i.e. a component that handles the transfer of control
among a set of coroutines by applying specific rules and conventions, can be added.
Since this is likely to be application specific, it is not included in the base module.
I would expect such things directly included with an application or, if there is a potential for reuse by others,
in a CPC package.

The trap handling code for coroutines is in Kernel. It is almost the same code as for the main stack.
When a coroutine traps, a trap viewer is opened that shows the stack of the coroutine.
Then control is transferred to main. If there is a follow-up trap in main, then a second trap window is opened
that shows the main stack.

- Josef

Re: issue-#156 adding Coroutines to BlackBox

Posted: Wed Apr 26, 2017 12:23 pm
by luowy
about "shared stack coroutine" concept you can google the web, the simple implmentation see here:https://github.com/cloudwu/coroutine and here https://github.com/Tencent/libco
the all implemented under linux, used for high performance web server, the second is industry.
it has domenstrated how useful the coroutine with shared stack for async io.

because the coroutine tranfer is not so easy used or understanded by common user, most coroutine implemetation has a concept scheduler to help coding, there are two class scheduler: iterator,task;
generator coroutine use iterator scheduler,it's coroutine no sleep action, only resume,yeild;
multitasking is a task scheduler, it's coroutines can sleep, resume,yeild; it implement "sleep" use Services.Action;
certainly,coroutine must has "state" field;
then user's can use "resume","yeild","sleep" can control the code flow in his coroutine "Run" body, all the transfer work is sent to it's scheduler, our framework can provide two std scheduler, Co_ package can implement it's own multitasking scheduler;

Re: issue-#156 adding Coroutines to BlackBox

Posted: Wed Apr 26, 2017 12:25 pm
by luowy
Josef Templ wrote:The trap handling code for coroutines is in Kernel
thanks, I will check it.

Re: issue-#156 adding Coroutines to BlackBox

Posted: Thu Apr 27, 2017 9:29 am
by Josef Templ
A very small last-minute change has been applied.

Iterator.Generate has been renamed to Iterator.Next.
This is the better and more commonly used name, e.g. in JavaScript, ...

In addition, calling Kernel.BeginCoroutines is delayed until the first
coroutine is actually initialized, i.e. not in the module body as before.

I hope this is OK for everybody.

- Josef

Re: issue-#156 adding Coroutines to BlackBox

Posted: Fri Apr 28, 2017 10:43 am
by Robert
luowy wrote:... certainly,coroutine must has "state" field ...
Josef, luowy.
I am confused.

I agreed to the vote now because I thought that the implementation discussion was not going forward anymore, but was only going round in circles, so it was time for some decision.

Is this a new behaviour discussion? Should we suspend / cancel the vote until this discussion reaches a conclusion (or stalemate)?

Re: issue-#156 adding Coroutines to BlackBox

Posted: Fri Apr 28, 2017 12:06 pm
by Josef Templ
Robert wrote:
luowy wrote:... certainly,coroutine must has "state" field ...
Josef, luowy.
I am confused.

I agreed to the vote now because I thought that the implementation discussion was not going forward anymore, but was only going round in circles, so it was time for some decision.

Is this a new behaviour discussion? Should we suspend / cancel the vote until this discussion reaches a conclusion (or stalemate)?
From my point of view this is not a discussion that affects the current implementation.

What luowy mentioned either exists or can be built on top of it, if required.
Coroutines already have a 'state' field.

Shared stack (alias stackless) coroutines:
This is an optimization for special cases offered by some languages
but it needs a language change and heavy optimizations in the compiler,
as far as I understand it. The compiler transforms a coroutine into a
state machine thereby. This is beyond the scope of this issue.

- Josef

Re: issue-#156 adding Coroutines to BlackBox

Posted: Fri Apr 28, 2017 2:34 pm
by luowy
Josef Templ wrote:Shared stack (alias stackless) coroutines:
This is an optimization for special cases offered by some languages
but it needs a language change and heavy optimizations in the compiler,
as far as I understand it. The compiler transforms a coroutine into a
state machine thereby. This is beyond the scope of this issue.
though you think your solution is good enough,but what I learn from the web and other language that we can make it more better,more useful, if we can implement the coroutine use stackless tech, maybe we can make a high performance web server compete with Node.js; that is the reason why I vote "no": accomplish it with one breath. I try to port libco or golang code to BB,it need some time; anyway, your solution is acceptable; let's leave the improvement to later.

Re: issue-#156 adding Coroutines to BlackBox

Posted: Tue May 16, 2017 12:18 am
by DGDanforth
noreply@z505.com wrote:On 2017-05-14 16:54, Douglas G Danforth wrote:
> BlackBox Component Pascal is currently implementing coroutines.


Interesting, are they going to learn from goroutines and erlang? There are some technical videos on youtube discussing it...

Maybe learn from the mistakes/experience/good things of other projects already attempting at solutions.

Re: issue-#156 adding Coroutines to BlackBox

Posted: Sun Jul 30, 2017 4:36 pm
by Robert
I have been using Coroutines for the first time (in BlackBox).
I wanted to iterate over a series of configurations defined using a recursive algorithm.

For my first attempt I used a plain Coroutine. This did take a little experimentation before correctly understanding how to use it correctly.

For my second attempt I used an Iterator. The final code was simpler, but actually I found the situation a bit more confusing. I attach below some possible extensions to the Docu that might make things clearer.

Another comment I have is regards the Obx Sys-Map. Is there an easy way to find it? Should opening it be an option on the Obx menu, or should there be a link to it in the menu item "Help->Contents"?
I wanted this map to get access to the Obx Coroutines examples.

While on the subject of the Contents map, it has a link to "What's New ?", which describes very old changes. I think a better title is required: ("Differences between Component Pascal and Oberon-2" ?).
But I do think there should be a link (called "Recent BlackBox changes" ?) to the file "BlackBox_1.7.1-a1_Changes.odc", and probably also to the file "BlackBox_1.7_Changes" (which is, currently, not in the latest distributions).
I am making this comment in response to some private communication with a previous BlackBox user who is now using BlackBox again after a 5+ years break. The lists of changes are valuable, but only if they are easy to find (for someone who does not even know they exist).
Iterator.pdf
Potential additional documentation
(49.65 KiB) Downloaded 313 times
Note that the Coroutine support code worked perfectly.

Re: issue-#156 adding Coroutines to BlackBox

Posted: Mon Jul 31, 2017 9:00 am
by Robert
Regarding Iterators:

1 - Would it be simpler for client code if the signature of Next was a function with a BOOLEAN return value? TRUE would mean the status was 'suspended', FALSE would mean 'returned'. Other statuses are, I think, impossible?

2 - It is possible (correct me if I am wrong) to call Coroutines.Transfer with an Iterator. I suspect that 99% of the time this would be done by accident, and 100% of the time it would lead to hard to read and understand code. So I suggest adding a documented TRAP to prevent this.
Of course it would still be called internally by Yield & Next.