Co_Routines Support for Oberon

http://www.zinnamturm.eu/downloadsAC.htm#Co_ http://sourceforge.net/projects/ta1/files/co2.0

Re: Co_Routines Support for Oberon

Postby luowy » Thu Apr 20, 2017 8:19 am

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/library/ms682117(v=vs.85).aspx and
https://msdn.microsoft.com/en-us/library/zxk0tw93.aspx
can you explain your code?
luowy
 
Posts: 12
Joined: Thu Dec 17, 2015 1:32 pm

Re: Co_Routines Support for Oberon

Postby Dmitry Dagaev » Thu Apr 20, 2017 4:42 pm

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.
Dmitry Dagaev
 
Posts: 55
Joined: Wed Mar 29, 2017 3:58 pm

Re: Co_Routines Support for Oberon

Postby Josef Templ » Fri Apr 21, 2017 9:59 am

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
Josef Templ
 
Posts: 126
Joined: Tue Sep 17, 2013 6:50 am

Re: Co_Routines Support for Oberon

Postby Dmitry Dagaev » Fri Apr 21, 2017 2:58 pm

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 ---
Dmitry Dagaev
 
Posts: 55
Joined: Wed Mar 29, 2017 3:58 pm

Re: Co_Routines Support for Oberon

Postby Dmitry Dagaev » Fri Apr 21, 2017 3:05 pm

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?
Dmitry Dagaev
 
Posts: 55
Joined: Wed Mar 29, 2017 3:58 pm

Re: Co_Routines Support for Oberon

Postby Josef Templ » Sun Apr 23, 2017 5:48 am

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
Josef Templ
 
Posts: 126
Joined: Tue Sep 17, 2013 6:50 am

Re: Co_Routines Support for Oberon

Postby Dmitry Dagaev » Sun Apr 23, 2017 1:44 pm

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?
Dmitry Dagaev
 
Posts: 55
Joined: Wed Mar 29, 2017 3:58 pm

Re: Co_Routines Support for Oberon

Postby Josef Templ » Mon Apr 24, 2017 6:55 am

if you can Transfer from B to A, isn't this in contradiction with the proposed
limitation of Transfer only to main?

- Josef
Josef Templ
 
Posts: 126
Joined: Tue Sep 17, 2013 6:50 am

Re: Co_Routines Support for Oberon

Postby Dmitry Dagaev » Mon Apr 24, 2017 8:00 am

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 Dagaev
 
Posts: 55
Joined: Wed Mar 29, 2017 3:58 pm

Re: Co_Routines Support for Oberon

Postby Dmitry Dagaev » Mon Apr 24, 2017 2:50 pm

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 https://community.blackboxframework.org/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 ;)
Dmitry Dagaev
 
Posts: 55
Joined: Wed Mar 29, 2017 3:58 pm

PreviousNext

Return to Co_

Who is online

Users browsing this forum: No registered users and 1 guest

cron