How do the different pthread implementations differ in how they determine
thread identity?
WRT linuxthreads specifically, are there any tricks that can be used to
multi-thread an application who's initial thread uses more than just the
default application stack?
Explanation:
I'm working on an application (VisualWorks Smalltalk virtual machine) that I
ported to Linux. The virtual machine("engine") uses 2 stacks: the
application stack (C stack) for execution of compiled C code, and a Smalltalk
stack on which Smalltalk bytecodes are jit compiled and executed. This
architecture has been in use for over a decade in industrial settings.....
The Smalltalk stack is located just above the process's data segment in
memory, so it's real far from the C stack...
We have a threaded api (THAPI) that allows programmers to thread off C library
calls (from shared C libs--used for database and socket accesses mostly). The
first call to pthread_create() doesn't happen until the programmer spawns off
their first threaded C api call....
The system runs properly under ADUX, Solaris, HPUX 11, etc... It appeared to
run properly under the linuxthreads implementation used in glibc 2.0.7...
What we've found (after running against glibc 2.1.1) is that the linuxthreads
implementation seems to assume that the "original process" (the one destined
to become __pthread_initial_thread) executes on only one stack, and that it is
the C stack. The problem is that thread identity is determined by comparing
the current %esp to the addresses of the existing threads.... So, if the
engine is running jit code on the Smalltalk stack and receives a signal, the
while loop in __pthread_find_self() flies off the end of the __pthread_handles
array and ends up returning the address of the __pthread_handles array which
is promptly written to (__pthread_handles[2] and __pthread_handles[5] are
seriously damaged).
Since I don't happen to have access to the source for any of the systems
except for Linux ;-) I'm now left guessing: How do HPUX/Solaris/ADUX
determine thread identity that doesn't depend on the value of the stack
pointer?
I'm interested in fixing this problem, but the linuxthreads implementation is
the only one I've seen the source to, so it's the only one I fully understand.
We've tossed around several potential solutions, but they all rely upon each
thread having it's own PID, which is apparently a quality of linuxthreads that
is in contention??
Any thoughts on this?
TIA-pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/