Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ncar!oddjob!gargoyle!ddsw1!gryphon!edk
From: edk@gryphon.CTS.COM (Ed Kaulakis)
Newsgroups: comp.lang.c
Subject: Re: Implementing co-routines etc.
Message-ID: <2948@gryphon.CTS.COM>
Date: 19 Mar 88 20:50:55 GMT
References: <4326@umn-cs.cs.umn.edu>
Organization: Trailing Edge Technology, Redondo Beach, Ca.
Lines: 23
Summary: thread (coroutine) === {stack pointer, program counter}

In article <4326@umn-cs.cs.umn.edu>, raghavan@umn-cs.cs.umn.edu (Vijay Raghavan) writes:
> 
>      Let me make it clear that this is *not* a feature that I want
> to see in D, or anything like that. I think that if co-routines
> are desired, a programmer can implement them on his own in C,
> with about the amount of portability that setjmp and longjmp
> have. I do have such an implementation (which, of course, I've
> never really had to use, except to satisfy myself that it
> works.) My problem is that I don't *like* the implementation. There
> is a particular bit of dirty coding which I can't seem to get
> around no matter how I shift and squirm. I think that this is 
> a peculiar situation where one *has* to resort to a little bit of
> kludgery in order to get the job done. But maybe I'm wrong. How 
> would *you* code the functions "instantiate" and "resume" to make
> the following program work?
> 

	Well, my opinion is that it can't be done in pure C, which doesn't
know anything about its own stack pointer. The stack pointer *must* be 
manipulated to give a coroutine the same kind of syntactic sugar on offset
references to its activation record (a mechanism often thought of as "auto"
variable allocation) that is enjoyed by regular C functions. Thus any 
coroutining code must kludgily mess with a hardware thingy that's not 
even declarable, for bizarre side-effect.