Path: utzoo!attcan!uunet!ficc!peter From: peter@ficc.uu.net (Peter da Silva) Newsgroups: comp.lang.c Subject: Re: Coroutines in C Message-ID: <5797@ficc.uu.net> Date: 21 Aug 89 02:18:33 GMT References: <5663@ficc.uu.net> <2151@netcom.UUCP> <5773@ficc.uu.net> <1989Aug19.230124.860@light.uucp> Organization: Xenix Support, FICC Lines: 39 In article <1989Aug19.230124.860@light.uucp>, bvs@light.uucp (Bakul Shah) writes: > 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 I'm not depending on setjmp/longjmp. I'm just pointing out that, *in many C compilers* it is possible to use setjmp/longjmp to implement the context switch. In my original posting on this subject I went into more detail on this subject. I am well aware of the Berkeley VAX compiler's stack unwinding on a longjmp. > 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. True. The compiler vendor can also change their calling sequence and invalidate your low level context-switch routines. A new version of the compiler is effectively a new compiler and a new porting effort for routines like this. Hopefully if they become standardised the compiler vendor will include them in the new release. > 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. You should pop back a few stack levels yourself :->, and have a look at my original proposal. I do keep the two concepts seperate, but designing things so a naive implementation of setjmp/longjmp (store all regs in jmp_buf in setjmp, restore them and do a return in longjmp) can be used to bootstrap the system is IMO a good idea. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "Optimization is not some mystical state of grace, it is an intricate act U of human labor which carries real costs and real risks." -- Tom Neff