>> This is really two bugs.

>> One is a bug in pth - it's trying to abuse setjmp/longjmp as a
>> general-purpose context switch mechanism, which it just isn't.
> For sure, it isn't what you're supposed to use setjmp for.

And as a result, it isn't something you can count on setjmp for.

> I think pth deserves some leeway, though, because being a portable
> thread library with almost no MD code isn't easy.

Since there is no portable context save/restore mechanism, a portable
thread library with no MD code is not possible, not short of something
like a complete C interpreter engine (or compiler to p-code, and p-code
engine).

I would recommend, for what it may be worth, that pth stop trying to
pretend it's free of MD code and drop in context save and restore
routines for each of the machines it supports, with a document to help
people write such routines for new machines.

>> Unfortunately, I can't see how to fix the latter without (a) adding
>> a controlled, advertised way to switch between stacks and (b) giving
>> up the botch detection normally provided by the blssu seven
>> isntructions into the longjmp code.

> Is this botch detection critical?

Perhaps not, but it's arguably better than walking off now-trashed
stack frames.

> Can longjmp be relaxed to just move to the target stack right away
> and not care?  This is what i386 and m68k do.

Sure it can - just restore the registers out of the jmp_buf and go,
instead of doing the stack unwind thing.  (I realize this may not be
much help to someone who doesn't know VAX assembly.  Unfortunately I
don't have time to go into more detail now.)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B