On Sun, 27 Jan 2002, Ralf S. Engelschall wrote:
Does anybody know what the problem with __errno_location in LinuxThreads
is?
I looked into this last week and it goes like this: __errno_location()
is a function that returns a pointer to errno from LinuxThreads'
internal structure representing the thread state. This stucture, struct
pthread_descr_struct, is pointed to by static variables for the first
two threads (the main thread and the manager thread) and for new
pthreads is located at the bottom of the stack for the default stack
size. Stacks are 2M by default and aligned on 2M boundaries.
So to return a pointer to errno, LinuxThreads needs to know what pthread
it's in. It does this by looking at the stack pointer. If you're in a
pth thread with a malloc'd stack, LinuxThreads has no way of knowing
what thread it's in because it can't do its funny stack math (looking
for the aligned boundary to find the pthread_descr_struct). errno is
where the problem shows up, but it's due to the more fundamental problem
of implementing pthread_self() by looking at the stack pointer.
I work with GStreamer, where we really do need gstreamer-scheduled
coroutines as well as kernel threads. We can't expect users to go out
and install ngpt, particularly when Debian (my distro of choice :)
doesn't have a package for it. Also, our coroutines implementation is
necessarily more lightwieght than pth's threads because we have our own
scheduler. In any case, I liked your mctx code, and i wanted it to work
with pthreads, so I worked out a hack (and it is a hack) for
linuxthreads and pth to cooperate. You have to copy the current thread's
pthread_descr_struct to the 2M aligned boundary that you're working in.
The real hack is how i got the pthread_descr, by locking a mutex and
looking in the mutex struct for the __m_owner field. It's not completely
in gstreamer's cvs yet, but it works in my simple tests. I'll post a
notice when i have it working properly, probably sometime in the middle
of this week. You're certainly welcome to use it (it's all LGPL), but it
might be distasteful ;-)
I would like to say thanks for making pth, it increases our portability
by quite a bit. We had our own machine context implementation, but it
relied on an assembler core for each architecture and could only work
within the stack of the current pthread, 2M by default, which was quite
limiting.
Best regards,
Andy Wingo
__
GNU Portable Threads (Pth)http://www.gnu.org/software/pth/
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager (Majordomo) [EMAIL PROTECTED]
