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 Dmitry Dagaev » Mon Apr 10, 2017 8:18 pm

Josef,

If I have different interfaces for Coroutines and Stack&Trap Cleaners, I can immediately add Stack&Trap Clean in Co.Stop implementation. This demonstrates the benefit of development in 2 different dimensions.

P.S. Nevertheless, your Co_ patch was effective and arguments about consistensy were valuable.
Dmitry Dagaev
 
Posts: 59
Joined: Wed Mar 29, 2017 3:58 pm

Re: Co_Routines Support for Oberon

Postby Josef Templ » Tue Apr 11, 2017 9:02 am

Dmitry Dagaev wrote:When I ran this example, I discovered that finalizers are called BEFORE the end on Coroutine Do.


Very strange indeed. Thanks for the report.
I cannot find the bug immediately but I am looking into it.
I guess that it is not specific to Co_ but a more general GC problem
possibly related to setting the stack ranges for marking.

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

Re: Co_Routines Support for Oberon

Postby Josef Templ » Tue Apr 11, 2017 3:08 pm

Dmitry Dagaev wrote:When I ran this example, I discovered that finalizers are called BEFORE the end on Coroutine Do.


The bug should be fixed now.
See http://blackboxframework.org/unstable/issue-%23156/blackbox-1.7.1-a1.847.zip.

The change in the 'Start' procedure you mentioned is not really required, at least not with the latest builds.
It should be possible to reuse the Kernel.Coroutine object after it has been
closed by calling Kernel.RemoveCoroutine. But this is a detail.

It may be possible to further simplify the Co_Routines module by
defining 'primary: Kernel.Coroutine. I have not looked into the details, though.

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

Re: Co_Routines Support for Oberon

Postby Dmitry Dagaev » Tue Apr 11, 2017 6:20 pm

Josef Templ wrote:The change in the 'Start' procedure you mentioned is not really required

That was the different case. In Co_ObxSameFringe example r1.Start(r1) was called twice for the same coroutine. It results in BB crash, because of Kernel.RemoveCoroutine(c.impl) is called, but NEW(c.impl) not. I fixed it.

The problem with finalizers is fixed, thanks.

If this version is the one to be based upon, I must mention again the problem with stack overflow. The example below causes recusion in coroutine, causing "stack overflow" on TrapViewer. Naturally fibers stack limits are different from main stack. If you run this example, you can see some memory damage in other places. In my computer, I failed to unload some modules. Maybe some trap cleaners should be modified.

StdCoder.Decode ..,, ..nO....3QwdONl9RhOO9vRbf9b8R7fJHPNGomCrlAyIhgs,CbKBhZ
xi2,CoruKu4qouqm8rtuGfa4.hOO9vRb1Y66wb8RTfQ9vQRtIdvPZHWKqtCa.E.U5U.p.6.5Qw
dONlnayKmKKqCLLCJuGqayKm6F9vQ5nsH3.bnayKmKa2,Cor.kay4.qorGqmQCU2,CJuyKtQC9
8P9PP7ONbXmb.2.AW2k5k2G.,6.kd4.86.QC18RdfQHfMf9R9vQ7ONb1E.kHE.0.p.0.4.0EJ2
XkD.6.VQ.k4k.8Mtf.2.010.u,2.AU.E.4ItaqkmaM2y,.,6YU8.5.3cUZj0E.6A2U.US.,.1.
42.4.072U5V,ob,k,8Mtf.2.01,6.c5E.k.0.42.8.07s1M.p07cUZj06.,..u,2.AU.U,,U.E
.mP,U22U.M.T2,c,M.L.zTHT8Ff8H9865uPzuH39Sb8R1vML9HHPPH9RrN1P68Jd8,N1HsMTfP
dfQHfMwhmRi7gbUIY2hhdZimBjUoeiYcVxgVhgqJYBAVgBhXhgiRiZ3Yx2YW2epJggBhX3Y2xh
hBgdphWgVeIZdgVBAV7hdExdGZeUQco3YugbUQcj7J1vQLvQN765uP,dCv76cITPRdPORPNb99
,tG9fQRPNN99,7HTvNrN1HM1H6Jn8I9O1HM0b8R1vMGpmCLu0mS0GcyoYuIeKId0GeyIECJu44
EWKqtCqRqk2akd.YCQgUgbUIe3RcDJe23YcQcjpZ1xhmxhpZCYcZlIqk2ak2mqoq4p76HeHdOF
DOFZuCPM0HMFR8FrN1HM10JdyoVKIWKJdKIEGpmCLu0GImqoqqo.UdQbBAV7oe,JeUIgppgahg
mJbUAcGJe,BfUAakIao2YDpcUQc6BcGRbBcE9uFHeHPM0HMGB86NPOPXUobU2aUYe6hcChV7M0
dONb9RF7PH1PNAHN1HM09WBAV3p7,7J9vQin4Ec.EWyKEWGueHECIuuGe4qtiqIin4a.sQdfC,
tIdPMUoV0,sQd96pVo3ZHZiV,AZvgV76J68b9RR7PHPPH9RHN1HMFRW2xhvgVBAVE,UGhiiJZv
gV7AVK,..r76PM03OF.ROFj88b9RHtCsQuGqUUIbxMAV7AV7AVlRqk2akVyKLaIraKuCor8rr.
FtQd99,7FTP8rN1QCCJu4KtGLICLua0UIJiVphnpgZJicQioB3gcCFdKLrin4qkWuIWQcjxfDV
oVA,RdUXDJ9X1xhiZimxhgZhZJinpZHZC58RZ9P7ONbvM,Mwd0.UiQcjpho,YcZRiX3.5011.8
5...CLL.U2V.IS2U.UIU.U72U.E..k.8ssHpmcIf9P9fQbf9bWGhigFWE.4Te.sQRdIf9P9HWE
.8z,E.0.L3D.53,6.C6.QiiQ8CJuaLqKKWKqtCK.4D.o3aLq.,cwF.,.E2EhE.0.32.oZ,ZCUZ
7F6.G.0..676.16.6.665hKE.4vl5UTyB4.4.0E.cUZj0E..UO.,.1.e0.,6Y1.0..yP0...
--- end of encoding ---
Dmitry Dagaev
 
Posts: 59
Joined: Wed Mar 29, 2017 3:58 pm

Re: Co_Routines Support for Oberon

Postby Zinn » Wed Apr 12, 2017 5:49 am

Dear Dmitry,

I followed the discussion about coroutines. This topic is very important for you. Which way, do you prefer?
1. Do everything in your subsystem Co_ without Blackbox coroutines support.
2. Using Josef's solution of Coroutines
3. Using Ivan's solution with HostCoroutines

I am not an expert in coroutines but Josef's 'consistency argument' is convincing to me.
HostCoroutines only makes it more complicated and dangerous to use.

- Helmut
Zinn
 
Posts: 58
Joined: Mon Nov 24, 2014 10:47 am

Re: Co_Routines Support for Oberon

Postby Dmitry Dagaev » Wed Apr 12, 2017 7:00 am

Dear Helmut,

The Co_ subsystem is used in several projects, at least it is implemented within Post-Accident Monitoring system for Rostov-1 NPP. I use some preprocessor for multi-platform development, so Co_ is for Win/Linux BlackBox/XDS/Ofront. The cross-platform solution works fine on all platforms, but there are 2 internal problems with coroutines.
1. GC (and trap cleaners under BlackBox) is not informed of local pointers, so if you define ptr and NEW(ptr) inside a coroutine, useful ptr can be marked for deletion;
2. There is no proper stack control.
In my projects I ensure all pointers in the main routine scope(1). The stack size can be easily controlled, if you use recursion.

These problems can be solved in Kernel support. I'm not in charge of developing BlackBox Kernel, so I published Co_ with these 2 known problems.

Josef decided to make Kernel support for GC (at least). My previous post shows that stack control problem persists too.

I was in opposition with Josef's solution and even demonstrated misunderstanding (it happened from both sides) claiming that his Kernel support is impossible. He proved the possibility, and yesterday I'have included configuration "#ifdef" for new version in my source. I'll publish the new Co_ in CPC when 1.7.1 is available.

But I'm still in favor of Ivan's solution. It should be useful, if he is going to make coroutines support in Linux version he is working with. It seems move convenient that he could use new Kernel support with Co_ implementation, based on contexts. The caller interface is Co_ which hides Kernel calls, avoiding consistency problem, mentioned by Josef.
I'll also include Ivan solution in Co_ package, if any.
Dmitry Dagaev
 
Posts: 59
Joined: Wed Mar 29, 2017 3:58 pm

Re: Co_Routines Support for Oberon

Postby Josef Templ » Wed Apr 12, 2017 7:20 am

Dmitry Dagaev wrote:If this version is the one to be based upon, I must mention again the problem with stack overflow. The example below causes recusion in coroutine, causing "stack overflow" on TrapViewer. Naturally fibers stack limits are different from main stack. If you run this example, you can see some memory damage in other places. In my computer, I failed to unload some modules. Maybe some trap cleaners should be modified.


So far I have not observed any stack overflow handling problems in module Coroutines.
In Co_ the trap handling is a problem in general because there is no transfer to main after detecting a trap.
I think this is the same problem for all kinds of traps within a Co_ coroutine.
Please look at the trap handling in Coroutines to see what needs to be done.

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

Re: Co_Routines Support for Oberon

Postby Dmitry Dagaev » Wed Apr 12, 2017 7:16 pm

Josef Templ wrote:there is no transfer to main after detecting a trap.

Extra cleaning was added, fixed, thanks.
Dmitry Dagaev
 
Posts: 59
Joined: Wed Mar 29, 2017 3:58 pm

Re: Co_Routines Support for Oberon

Postby Josef Templ » Thu Apr 13, 2017 8:27 am

With the last build I have added support for multiple client modules.
Now both Coroutines and Co_Routines can be loaded and used.

A small adaptation in the interface has been necessary for achieving that.
In addition, InitCoroutines has been split into BeginCoroutines and EndCoroutines
for better readability.

Code: Select all
   PROCEDURE InitPrimary;
      VAR m: MainCoroutine;
   BEGIN
      NEW(m); NEW(m.impl);
      Kernel.BeginCoroutines(m.impl);
      ASSERT(m.impl # NIL, INTERNAL_ERROR);
      primary := m;
   END InitPrimary;

   PROCEDURE Close;
   BEGIN
      IF primary # NIL THEN
         primary.impl := NIL;
         Kernel.EndCoroutines
      END
   END Close;



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

Re: Co_Routines Support for Oberon

Postby Dmitry Dagaev » Thu Apr 13, 2017 3:57 pm

Checked with last build.
Dmitry Dagaev
 
Posts: 59
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