Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!diku!daimi!pederch
From: pederch@daimi.UUCP (Peder Chr. N|rgaard)
Newsgroups: comp.lang.modula2
Subject: Re: Coroutines vs. Operating Systems
Message-ID: <461@daimi.UUCP>
Date: Mon, 24-Nov-86 04:55:20 EST
Article-I.D.: daimi.461
Posted: Mon Nov 24 04:55:20 1986
Date-Received: Tue, 25-Nov-86 21:01:01 EST
References: <8611201656.AA00169@odysseus.sun.uucp>
Reply-To: pederch@daimi.UUCP (Peder Chr. N|rgaard)
Organization: DAIMI: Computer Science Department, Aarhus University, Denmark
Lines: 32

At out site we have used a Modula-2 implementation for 
about a year. Based on this experience we will urge you
to stick to approach B, that is, implement NEWPROCESS
and TRANSFER only, and forget everything about IOTRANSFER,
which doesn't fit into the UNIX environment at all. The ar-
gument in your point D just does not hold: UNIX processes
have too much overhead to be used extensively as a control
structure tool.

Actually, we use the NEWPROCESS/TRANSFER mechanism not only
as a part of Modula-2 system. Personally, I have written two
systems in C, one of those a SunTool, both centered around
a scheduling select(2) call, using the coroutine mechanism
to simplify control structures which would otherwise have 
to be implemented using a lot of global state variables.

Furthermore we have implemented a simple light-weight process
kernel in Modula-2 based on the coroutine concept.

The only serious problem we have run into is this: how
do you estimate the size of the stack needed for a co-
routine? and, worse, how do you ensure that your estimate
was large enough? To the best of my knowledge, the 68000
processsor has no built-in stack overflow test. This is no
problem when you have only a few coroutines - in a virtual
memory you can just give them each a Megabyte. But problem
arises when you wish to use, say, a 1000 coroutines in the
same process.

Peder Chr. N|rgaard	Computer Science Department
			Aarhus University
			Denmark