Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!spool.mu.edu!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: <13818@dog.ee.lbl.gov>
Date: 2 Jun 91 12:27:31 GMT
References: <1991May20.123423.10388@linus.mitre.org> <4815@skye.ed.ac.uk> <13598@dog.ee.lbl.gov> <10728@castle.ed.ac.uk>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 54
X-Local-Date: Sun, 2 Jun 91 05:27:31 PDT

In article <10728@castle.ed.ac.uk> simon@castle.ed.ac.uk (Simon Brown) writes:
[an involved method for guaranteeing up-stack-jumps]
>But this is pretty slow, as it needs to handle a signal on each reschedule.
>And pretty disgusting too, come to think of it.

Indeed. :-)

>Such as a change which causes longjmp to destructively unwind the stack, say.
>(I seem to have a vague clouded memory that the V7 longjmp did this? Or maybe
>it was 4.1BSD)

4BSD VAX longjmps have done this for some time.  It correctly restores
the values of registers, so that

	register int f = 0;
	(void) setjmp(label);
	printf("%d\n", ++f);
	longjmp(label, 1);

prints

	1
	2
	3
	.
	.
	.

Many `typical' implementations print

	1
	1
	1
	.
	.
	.

The BSD Vax unwind looks essentially like this:

	while (fp != desired frame) {
		if (we are above the desired frame) {
			write(2, "longjmp botch\n", 14);
			dump core;
		}
		stuff our own address into the return pc;
		``return'';
	}

and hence if you have mucked with the stack, and the frames are not
in a single chain leading to the top, you will lose out.  The BSD tahoe
unwind is almost identical.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov