Co_Routines Support for Oberon

http://www.zinnamturm.eu/downloadsAC.htm#Co_ http://sourceforge.net/projects/ta1/files/co2.0
Dmitry Dagaev
Posts: 68
Joined: Wed Mar 29, 2017 3:58 pm

Re: Co_Routines Support for Oberon

Post by Dmitry Dagaev »

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

Re: Co_Routines Support for Oberon

Post by Josef Templ »

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: 262
Joined: Tue Sep 17, 2013 6:50 am

Re: Co_Routines Support for Oberon

Post by Josef Templ »

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

Re: Co_Routines Support for Oberon

Post by Dmitry Dagaev »

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 ---
Zinn
Posts: 123
Joined: Mon Nov 24, 2014 10:47 am
Location: Frankfurt am Main
Contact:

Re: Co_Routines Support for Oberon

Post by Zinn »

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

Re: Co_Routines Support for Oberon

Post by Dmitry Dagaev »

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

Re: Co_Routines Support for Oberon

Post by Josef Templ »

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

Re: Co_Routines Support for Oberon

Post by Dmitry Dagaev »

Josef Templ wrote:there is no transfer to main after detecting a trap.
Extra cleaning was added, fixed, thanks.
Josef Templ
Posts: 262
Joined: Tue Sep 17, 2013 6:50 am

Re: Co_Routines Support for Oberon

Post by Josef Templ »

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

Re: Co_Routines Support for Oberon

Post by Dmitry Dagaev »

Checked with last build.
Post Reply