Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!murtoa.cs.mu.oz.au!munnari.oz.au!mimir!hugin!augean!idall
From: idall@augean.OZ (Ian Dall)
Newsgroups: comp.lang.c
Subject: Re: Coroutines in C
Message-ID: <563@augean.OZ>
Date: 15 Aug 89 01:40:48 GMT
References: <5663@ficc.uu.net> <14281@haddock.ima.isc.com>
Organization: Engineering Faculty, University of Adelaide, Australia
Lines: 25
Reply-To:

In article <14281@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
>In article <5663@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>>Isn't it about time that there was some effort made to provide a standard
>>coroutine library in C.
>
>Wasn't there such a library (cofork(), cowait(), etc.) for the pdp11 back in
>V6 or early V7?  I never used it, but I recall having seen it described.

My V6 manual (chapter 7) documents crfork, crread, crwrite, crexch and cprior.
It says "The activation record for each function execution is dynamically
allocated rather than stacked." It goes on to say that there is a big overhead
in doing this! It is however possible to specify an alternate stack as an
optional argument to crfork and avoid this overhead. The scheme seems workable
but portable implimentation is no doubt impossible and it may not be possible
to impliment at all on some machines. Would making the coroutine functions
compiler "builtin" inline functions allow implimentation on a larger variety
of machines?

What sort of problems do you want coroutines for? I seem to have survived about
14 years of programming without ever using them!

-- 
 Ian Dall           life (n). A sexually transmitted disease which afflicts
                              some people more severely than others.
idall@augean.oz