Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!agate!dog.ee.lbl.gov!elf.ee.lbl.gov!torek From: torek@elf.ee.lbl.gov (Chris Torek) Newsgroups: comp.unix.internals Subject: Re: threads without kernel mods Message-ID: <13598@dog.ee.lbl.gov> Date: 28 May 91 00:57:59 GMT References: <213@titccy.cc.titech.ac.jp> <1991May20.123423.10388@linus.mitre.org> <4815@skye.ed.ac.uk> Reply-To: torek@elf.ee.lbl.gov (Chris Torek) Organization: Lawrence Berkeley Laboratory, Berkeley Lines: 27 X-Local-Date: Mon, 27 May 91 17:57:59 PDT In article <4815@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >... Once you have n stacks, you may be able to longjmp() between them. And then again, you may not.... Longjmp is only defined for going `up' the stack, and can (and does) abort programs that attempt to use it in the `wrong' direction. When you have two separate stacks and attempt to jump from one to the other, you are going neither up nor down, but the `<' comparison done internally gives an answer anyway (which answer it gives depends on the relative addresses of the two separate stacks) and thus implementations that check (such as 4.xBSD-on-a-VAX) may stop your code dead, rather than changing stacks. It is not impossible to implement this, but it *is* heavily machine dependent. Chances are you will get the best results not by trying longjmp(), but rather by reading up on the machine's calling conventions, the O/S's user stack conventions, and the machine architecture, and writing the context switch code only once you understand all of these. It is probably best to continue to avoid setjmp/longjmp as their specifications have changed in the past, suggesting that they may change again in the future. (Richard Tobin, I note, used _longjmp. This is what used to be called longjmp. POSIX now has sigsetjmp, apparently. In other words, this is dangerous territory. You should know exactly what you are doing, or you will step on a land mine.) -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov