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]
