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