Thread support in 0.10 on OpenBSD

Robert S. Thau rst at ai.mit.edu
Tue Mar 31 15:52:06 PST 1998


tank at iroquois.mcla.org writes:
 > I see that the full size of the setjmp buffer is (long)10 in
 > OpenBSD-i386 but have not been able to find the area in soure where
 > the offset to the stack ptr is...  Any ideas on where in a source tree
 > (BSD) this is usually located?

Typing "disassemble longjmp" in gdb can be enlightening; it generally
isn't *too* hard to figure out where it's getting the value which gets
loaded into the stack pointer.

One other last-ditch suggestion, also from the aforementioned threads
experiment: if you can't figure out *any* other way to initialize a
jmp_buf for a new thread context, and the system you're running on
supports some form of sigstack() or sigaltstack() call, you can use
that to do the setup.  The trick is excessively wasteful of both
processor time (it involves sending a signal at every thread creation)
and memory (it puts a few hundred bytes of crud on the bottom of every
thread's stack which is never used later), but if it works, it does
let you set up threading without having to figure out anything at all
about jmp_buf layout (or other processor-dependant matters).

The trick is this: when you want to create a new thread, you make its
stack the signal stack for a signal which your app would not otherwise
need to process, do a setjmp to save the state of the creating thread,
and then send yourself that signal.  The signal handler now finds
itself running on the new thread's stack.  It can therefore do a
setjmp(), initializing state for the created thread (including a
correct stack pointer value), and then longjmp() back into the context
for the creating thread.  

I've put a snapshot of my experimental threads code, in its most
recent state, on ftp://ftp.ai.mit.edu/pub/rst/rsthreads.tgz for those
who would like to see what this looks like --- there are a few tricky
details.  BTW, this also includes code to do a non-blocking DNS lookup
from a local BIND server (which is great if you know that all your
users are using BIND, but does you no good at all if they're doing
name resolution through, say, NIS or NIS+).

rst




More information about the kaffe mailing list