Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdcad!light!bvs
From: bvs@light.uucp (Bakul Shah)
Newsgroups: comp.lang.c
Subject: Re: Coroutines in C
Message-ID: <1989Aug19.230124.860@light.uucp>
Date: 20 Aug 89 06:01:21 GMT
References: <5663@ficc.uu.net> <2151@netcom.UUCP> <5773@ficc.uu.net>
Reply-To: bvs@light.UUCP (Bakul Shah)
Organization: Bit Blocks, Inc.
Lines: 36

In article <5773@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>
>                            In many C compilers I wouldn't even need
>to write any assembly code, since setjmp/longjmp can be used to implement
>the context switch.

You are better off not depending on setjmp/longjmp for this because

    1.  In addition to jumping where a setjmp() was done, longjmp() pops
	zero or more frames (activation records) off the top of frame
	stack.

    2.  A longjmp() is guaranteed to work only if it is called on the
	same stack as its corresponding setjmp().

    3.  On some machines, one must rely on the stack being the same to
	properly implement setjmp/longjmp.

    4.  Some implementations use longjmp()'s property of *shortening*
	the stack to catch an invalid use of longjmp (e.g. `longjmp
	botch' message on 4.3 bsd).

    5.  In a context switch you don't want to pop frames, you want to
	switch stacks.

Even in cases where you can get away with using them for coroutine
`context switch' now, the compiler vendor may rightfully decide to
check for 4. above in a later version.

It would be nice to have a standardized (but optional) coroutine
facility (if an implementation provides it, one can depend on a standard
inteface and behavior) but there is not reason to mix them up with
setjmp/longjmp.  By keeping the two concepts separate you would not add
any additional constraints on or be constrained by setjmp/longjmp.

-- Bakul Shah <..!{ames,sun,ucbvax,uunet}!amdcad!light!bvs>