Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!mips!news.cs.indiana.edu!att!cbnewsm!cbnewsk!pegasus!hansen
From: hansen@pegasus.att.com (Tony L. Hansen)
Newsgroups: comp.unix.internals
Subject: Re: threads without kernel mods
Summary: see class process in The C++ Answer Book
Message-ID: <1991Jun8.030135.13605@cbnewsk.att.com>
Date: 8 Jun 91 03:01:35 GMT
References: <1991May20.123423.10388@linus.mitre.org> <4815@skye.ed.ac.uk> <13598@dog.ee.lbl.gov>
Sender: hansen@cbnewsk.att.com (tony.l.hansen)
Organization: AT&T Bell Laboratories
Lines: 45

< From: torek@elf.ee.lbl.gov (Chris Torek)
< 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.)

I faced this problem when I needed to create a semi-portable task library for
The C++ Answer Book. I wound up using setjmp/longjmp to do it because I
restricted myself to not using any assembly code and to knowing as little
about the stack frame as possible. I used the real stack for the stack, but
copied it out to the heap and then back in whenever I needed to do a context
switch.  In order to get around the problem of longjmp only working when it's
executed above where it was created, I used the simple expedient measure of
recursively invoking my function until my address was indeed above the right
limit. (This method was dreamed up with help from Jonathan Shopiro.) And then
longjmp worked just fine.  The scheme I used fails in two environments: if
you have multiple stacks, such as a separate register stack on Sparc's; and
if your version of longjmp attempts to walk the stack frames.  I do wish that
the libraries which contained the stack frame walking versions of longjmp
also contained a non-walking version. If they did, then this scheme can work
on even more operating systems.

					Tony Hansen
			    hansen@pegasus.att.com, tony@attmail.com
				att!pegasus!hansen, attmail!tony