Page 8 of 10

Re: Co_Routines Support for Oberon

Posted: Thu Apr 20, 2017 8:19 am
by luowy
Dmitry,
why you set the [ccall] calling convention ?

Code: Select all

MODULE Co_Api ["Kernel32.dll"];

(** 
	contributors	= "Dmitry V.Dagaev"
	license = "Public Domain"
**)

	IMPORT WinApi;
	
	CONST FIBER_FLAG_FLOAT_SWITCH* = 0;
	
	PROCEDURE [ccall] ConvertThreadToFiberEx* (lpParameter: WinApi.PtrVoid; dwFlags: INTEGER): WinApi.PtrVoid;
	
	
	PROCEDURE [ccall] ConvertFiberToThread* (): INTEGER;

END Co_Api.
according to the msdnhttps://msdn.microsoft.com/en-us/librar ... s.85).aspx and
https://msdn.microsoft.com/en-us/library/zxk0tw93.aspx
can you explain your code?

Re: Co_Routines Support for Oberon

Posted: Thu Apr 20, 2017 4:42 pm
by Dmitry Dagaev
Co_Api Module is deprecated, not imported by Co_Routines. Co_ for new Kernel uses Kernel.* interface. Co_ for old Kernel uses WinApi.CreateThreadToFiber calls. Co_Api was used, because I tried to choose between WinApi.CreateThreadToFiber and Co_Api.CreateThreadToFiberEx 2 years ago. I've chosen WinApi.CreateThreadToFiber at last.
Intermediate version with [ccal] CreateThreadToFiberEx was working some time ago, I dont know, how ;) .

Finally, thanks, I'll clean Co_ once more for deprecated modules.

Re: Co_Routines Support for Oberon

Posted: Fri Apr 21, 2017 9:59 am
by Josef Templ
Dmitry Dagaev wrote:
Josef Templ wrote: It is easy to construct perfectly meaningful applications that cannot be implemented with Co_.
Can you, please, show any example?
What about nested iterators, for example.
If an iterator A is implemented as a coroutine and that coroutine uses
another iterator B that is also implemented as a coroutine, then
B has to transfer control to A, not to main.

- Josef

Re: Co_Routines Support for Oberon

Posted: Fri Apr 21, 2017 2:58 pm
by Dmitry Dagaev
Josef Templ wrote:
Dmitry Dagaev wrote:
Josef Templ wrote: It is easy to construct perfectly meaningful applications that cannot be implemented with Co_.
Can you, please, show any example?
What about nested iterators, for example.
If an iterator A is implemented as a coroutine and that coroutine uses
another iterator B that is also implemented as a coroutine, then
B has to transfer control to A, not to main.

- Josef
Quite simple: main calls B, B calls A for increment value.
Result is: 0 1 2 ... 10 20 30 ... 110 210 310 ...

Code: Select all

	TYPE
		Ait = POINTER TO AitDesc;
		AitDesc = RECORD (Co.CoroutineDesc)
			v: INTEGER;
		END;
		
		Bit = POINTER TO BitDesc;
		BitDesc = RECORD (Co.CoroutineDesc)
			a: Ait;
			v: INTEGER;
		END;
		

	PROCEDURE (a: Ait) Do;
	BEGIN
		a.v := 1; Co.Yield;
		a.v := 10; Co.Yield;
		a.v := 100; Co.Stop;
	END Do;
	
	PROCEDURE (b: Bit) Do;
		VAR j, k: INTEGER;
	BEGIN
		FOR j := 0 TO 2 DO
			b.a.Transfer;
			FOR k := 0 TO 9 DO
				Co.Yield;
				INC(b.v, b.a.v);
			END
		END;
		Co.Stop;
	END Do;
	
	PROCEDURE Run*;
		VAR b: Bit;
	BEGIN
		NEW(b); b.Start;
		NEW(b.a); b.a.Start;
		WHILE ~b.eor DO
			b.Transfer;
			Log.String("Val="); Log.Int(b.v); Log.Ln
		END;
		Log.String("End");Log.Ln;
	END Run;
For new Kernel:
StdCoder.Decode ..,, ..BS....3QwdONl9RhOO9vRbf9b8R7fJHPNGomCrlAyIhgs,CbKBhZ
xi2,CoruKu4qouqm8rtuGfa4.hOO9vRb1Y66wb8RTfQ9vQRtIdvPZHWKqtCa.E.U5UOw.2U.Qk
lbeZ3DPuP7PNNvQRtId9NPuP7X2hgnRAXDJ.QCPuP7PNG2sET1.PuP.MHT9N9nt.G2sIdvPZnt
gcghghZcZRC8T0E.kpH.T.5D,2U..hP.cU.ktAcoZimBhWhiohgnZcZRC.,.D,,6.IX.U.U,U.
I3l6w1.0E65.21AU0Ky8.,UkU.US.,.16.MEZPO19PWFs5U,UE0,cFE,E,8Mtf.0E.s8E.c5E.
k.U,,U.E.07c43U1IkmL,6.o66.o16.M.kU..0ES9.Y.IUx0Z.3s.E.E2PP,2eHJ.3Qw7ONhvE
TPPPPMR9N9fQbf9b8RO3U.Ay2hgq,.RdJ.0EtD.2..c,6.,k8E5E,G.yzayIWKJaKIECorypb8
KwGpvyqYGrm8bvgVB2ZeIZUgV7QgjphoJidJAyKtCr2qHE8GWqqoGLtaLEOJLGokSqkKKv8m4a
EqaqlKKrCrm0mS0GF0pu8Kqaql0GWyqq4qouKFqEJemIqk2qk2aoa0pb8Je0mVyKEenS0mVyaG
xhpZidphZRig2YAxhbRbBAVBAVIBfEhcBAV7AcdZiUgbU2eDBdCZe3JeUYeD3Y,BhoZcZRiXl2
akU6F66v76ZOF5uHZ8F,785uPRtETfQTPRd17ONAZBAV7AVqJbUAdCZe3xc3JevgV7AV3pd2Rb
BAV7gV7cEH9R,ND.83IcdZi2hAi18270,,...UdU7Agu2Y,BhoRbBA,HcR.D0MF.PM1H6IZuH5
OF7OJZOF,781fC,NEAZUYcjRbBAV0hc5BdChV7AVVpZq3YugbUAav2Y1xhiAfdhggZgvg,44Uk
QbUQcj,..6Ar765WHZij3ivgV7gcC767uPrVB6I.EleHE8ooGrI00M0hOEZ86J99,tOp76HeH.
I6.BuHZ86J96pND0HEGpb0GN0GWyo4ak2aElumkuGe8rkuqtOqm8rRqk2aU4Vf3Yug5Ut2Y2xd
BU7QcjpZN,M0akYuoVWGluGvmGE8KL4KLOrIin4ak2g6qk2akWsCsEQ8U3FE.PEc.EdKLremRq
k2o8Igu22QbBcE.uoWSJI8qIiHE8KLCJu4KtGrRqk2aEbUiAgdQbUIA1f9b8R11sJFOGNOF,dT
3f99vPZ967uHM03He8rk.UAxhbpZHZimBhixgcIYKBgghbWAZv2YAxhbpZ7pho3ZWpZqBZv226
HRP1HM09WvUAVH,MFR9N3N8r7HTvNR7Hin4akW66ZORRvCPM0PMFR8FCorypb.UigVBIU1xhTx
7.EdKLr8ssHpmsETfPdnrmKqKKtCbH7N58RZ9P7ONbH.4Te..c95uPR9R.7ONbvM,kVkk.Um,.
.Unp3.6F6.ZD,6.636.M00U.2..AU0CyIhA8pumqm8rtumdcIf9PY62Ulb8.CLL8ZghA70,cw5
.0.L3D.53,6.C6.QiiQ8CJuaLqKKWKqt2Ul1.RVtZBE.8T2E..2,I92U.E,,.RNEd1MNG20U2U
...G00k.0.0.0mFf32UlSw,sbTX,U,U.2.8Mtf.2..c4,.,.1.e0.,6Y1.0..bb,...
--- end of encoding ---

Re: Co_Routines Support for Oberon

Posted: Fri Apr 21, 2017 3:05 pm
by Dmitry Dagaev
Co_ObxMJackson old example contains pipes (PipeInit, More) with nested coroutines. Main calls pipe, pipe calls buffer, buffer returns to pipe.
Any other perfectly meaningful application (that cannot be implemented with Co_), maybe?

Re: Co_Routines Support for Oberon

Posted: Sun Apr 23, 2017 5:48 am
by Josef Templ
Dmitry Dagaev wrote:
Quite simple: main calls B, B calls A for increment value.
Result is: 0 1 2 ... 10 20 30 ... 110 210 310 ...
Are we talking about the same example?
In my example, main transfers to A
A creates B
A transfers to B
B transfers to A
A transfers to B
B transfers to A
...
A transfers to main
main transfers to A
A creates B
A transfers to B
B transfers to A
A transfers to B
B transfers to A
...

- Josef

Re: Co_Routines Support for Oberon

Posted: Sun Apr 23, 2017 1:44 pm
by Dmitry Dagaev
We are talking about
nested iterators, for example ... B has to transfer control to A, not to main
In the example above:
main Transfers to b
b Transfers to a
a.v := 10
a Yields to b
INC(b.v, 10)
b Yields to main.

It means that Co_ supports nested iterators.

Any other example?

Re: Co_Routines Support for Oberon

Posted: Mon Apr 24, 2017 6:55 am
by Josef Templ
if you can Transfer from B to A, isn't this in contradiction with the proposed
limitation of Transfer only to main?

- Josef

Re: Co_Routines Support for Oberon

Posted: Mon Apr 24, 2017 8:00 am
by Dmitry Dagaev
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.

Re: Co_Routines Support for Oberon

Posted: Mon Apr 24, 2017 2:50 pm
by Dmitry Dagaev
Robert wrote:And what about the overlap between the 2014 Co_ subsystem and the 2017 Center proposals? Is it large overlap? Is it a good thing? Is it a bad thing?
Josef Templ wrote: The center's Coroutines are general purpose while the Co_ package,
as far as I understand it
Several final cuts about two subsystems should be done from my side. I'll try to base on evidence, but not on assumptions and attempts to understand.

1. It was claimed, that Co_ cannot implement meaningful applications, that can be implemented by "general purpose" Coroutines. Josef Templ failed to prove this claim.
2. The ObxCoroutine demonstates the same examples, as Co_: Co_ includes Co_ObxSameFringe and Co_ObxActions examples, ObxCoroutine includes SameFringe and ObxActions named as Primes.
3. Co_ includes Cooperative Multitasking support. There are general purpose multitasking examples, implemented in Co_, which are out of center's Coroutines scope :
  • ObxPhilosophers - Dining Philosophers multitasking problem with semaphores
  • ObxProducerConsumer - Producers and Consumers multitasking
  • ObxReadersWriters
4. I would not recommend using center's Coroutines to a novice (Robert asked about this), because it uses Transfer instead of Yield to return from Coroutine viewtopic.php?f=54&t=164&start=10#p957. Like starting to play piano, basic technics is very important, especially for a novice.

So center's Coroutines package is just a partial implementaion of Co_ functionality in author's own way.
Co_ package is designed to cover all the needs of all kings of users. Yes, there is deep understanding of various types of problems, based upon it.

But at least there are some major points in developing center's Coroutines package:
1. Josef Templ implemented coroutine's stacks and traps Kernel support;
2. A comprehensive discussion was initiated ;)