From: Perry E. M. <pe...@pi...> - 2004-03-31 03:26:02
|
The BSD ports currently don't have thread support. Are there objections to my conditionalizing the spinlocks in the runtime on the thread feature? This fixes a couple of lurking bugs for my NetBSD port, and they serve no purpose on any port without threads, so it seems like an obvious thing to do... If people agree, I'll submit the patches in my next batch of runtime cleanups... -- Perry E. Metzger pe...@pi... |
From: Daniel B. <da...@te...> - 2004-03-31 19:56:39
|
"Perry E. Metzger" <pe...@pi...> writes: > The BSD ports currently don't have thread support. Are there > objections to my conditionalizing the spinlocks in the runtime on the > thread feature? This fixes a couple of lurking bugs for my NetBSD > port, and they serve no purpose on any port without threads, so it > seems like an obvious thing to do... The intention (and I haven't checked to see if this is really the case) was that the functions getting and releasing spinlocks would be declared static inline and therefore a reasonably smart compiler (as opposed to the mythical SSC) at reasonable optimization levels would optimize calls to them into nothingness on thread-challenged platforms. As I say, I haven't tested to see if this is really the case. All other things being equal I'd rather not fill the C ocde with ifdefs where they're avoidable. -dan -- "please make sure that the person is your friend before you confirm" |
From: Perry E. M. <pe...@pi...> - 2004-03-31 20:22:37
|
Daniel Barlow <da...@te...> writes: > "Perry E. Metzger" <pe...@pi...> writes: > >> The BSD ports currently don't have thread support. Are there >> objections to my conditionalizing the spinlocks in the runtime on the >> thread feature? This fixes a couple of lurking bugs for my NetBSD >> port, and they serve no purpose on any port without threads, so it >> seems like an obvious thing to do... > > The intention (and I haven't checked to see if this is really the > case) was that the functions getting and releasing spinlocks would be > declared static inline and therefore a reasonably smart compiler (as > opposed to the mythical SSC) at reasonable optimization levels would > optimize calls to them into nothingness on thread-challenged > platforms. They can't. First, the C compiler doesn't know if you have access to a thread library or not, and even if it did, it wouldn't know that the contents are meaningless in a non-threaded program. Even if it did know, the calls contain (necessarily) assembler to get access to instructions to do mutual exclusion, and the compiler cannot know the semantics of the contents. gcc effectively ignores the contents of those calls for optimization purposes. Executing the instruction, of course, causes a bus lock (so that on MP boxes you're sure of exclusion) and a cache write-through (so that you're sure the other processors got your update). Not cheap. Additionally, because the compiler cannot know what you're doing with the variables you pass behind its back, it treats the calls as barriers and assumes it has to re-load any touched variables and can't reorder code across the asm boundaries. > All other things being equal I'd rather not fill the C ocde with > ifdefs where they're avoidable. The #ifdefs are simple and are found all over the rest of the file anyway. Can I use them? Perry |
From: Christophe R. <cs...@ca...> - 2004-03-31 21:03:58
|
"Perry E. Metzger" <pe...@pi...> writes: > Daniel Barlow <da...@te...> writes: >> All other things being equal I'd rather not fill the C ocde with >> ifdefs where they're avoidable. > > The #ifdefs are simple and are found all over the rest of the file > anyway. Can I use them? Just a thought -- might it be better to (a) rename get_spinlock to get_sbcl_threads_spinlock (or something that definitely signals that it should only be used to resolve internal contention; not to interface with any other form of lock on the platform, and (or "or", if get_spinlock is already idiomatic for that) (b) write a non-threaded version of get_spinlock() and release_spinlock() on the x86, such that the appropriate one will be chosen depending on LISP_FEATURE_SB_THREAD. Then the operation of get_spinlock() will be *word = value; or equivalent -- certainly cheaper than lock cmpxchg. NOTE NOTE NOTE: (b) involves sbcl.h being included before target-arch.h in every single file, otherwise Bad Things Will Happen. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: Perry E. M. <pe...@pi...> - 2004-03-31 21:53:40
|
Christophe Rhodes <cs...@ca...> writes: >> The #ifdefs are simple and are found all over the rest of the file >> anyway. Can I use them? > > Just a thought -- might it be better to > > (a) rename get_spinlock to get_sbcl_threads_spinlock (or something > that definitely signals that it should only be used to resolve > internal contention; not to interface with any other form of lock on > the platform, and (or "or", if get_spinlock is already idiomatic for > that) Dunno. Perhaps. I think the existing names are reasonable, though I suspect that instead of rolling one's own threads, using the pthreads interface from the operating system would be far superior. Then one can simply use the various pthreads_mutex calls to do mutual exclusion, and one gets access to the OS's thread scheduler interfaces. That's a whole other story, though. Right now I just want to #ifdef thread specific code in the non-threaded case. > (b) write a non-threaded version of get_spinlock() and > release_spinlock() on the x86, such that the appropriate one will be > chosen depending on LISP_FEATURE_SB_THREAD. Then the operation of > get_spinlock() will be *word = value; or equivalent -- certainly > cheaper than lock cmpxchg. There isn't any use in the code for spinlocks outside of thread exclusion, so it isn't clear that we need a non-threaded version. -- Perry E. Metzger pe...@pi... |
From: Daniel B. <da...@te...> - 2004-03-31 22:12:12
|
"Perry E. Metzger" <pe...@pi...> writes: > Dunno. Perhaps. I think the existing names are reasonable, though I > suspect that instead of rolling one's own threads, using the pthreads > interface from the operating system would be far superior. Then one There are two reasons we don't use the pthreads interface (1) the 'LinuxThreads' implementation of pthreads as used in Linux 2.4 is absolutely fucking awful, and screws up any program that attempts to use signals for anything more complex than "duh, an error happened, let's print a message and exit". As we use signals for all kinds of stuff including a write barrier for the GC, this was not an option. (2) Accessing dynamically bound special variables requires thread-local storage. Conceded that these tend to get used less often than lexical variables, but even so, doing a foreign call into C for every special variable access would (my gut feeling) be so slow it wouldn't even qualify as a joke. Not to mention involving interesting circularity issues with e.g. the way that WITHOUT-INTERRUPTS works (1) really isn't a big deal any more (in fact we recommend linux 2.6 for threaded sbcl anyway), but any pthreads-compatible sbcl is going to have to work out how to cope with (2) sanely, and right now I don't have the time. -dan -- "please make sure that the person is your friend before you confirm" |
From: Ted L. <me...@fu...> - 2004-03-31 22:35:19
|
On Mar 31, 2004, at 4:20 PM, Daniel Barlow wrote: > (1) really isn't a big deal any more (in fact we recommend linux 2.6 > for threaded sbcl anyway), This is good news - I haven't been following the pthreads implementation in Linux 2.6, but if the quality is good, using it would be nice, since then we'd get threads on other POSIX-threads-compliant systems for free. > but any pthreads-compatible sbcl is going > to have to work out how to cope with (2) sanely, and right now I don't > have the time. So probably there would have to be some system-specific code generation to deal with this. So pthreads doesn't give us threads for free, exactly, but I suspect it's still a net win - having a threads package that's Linux-only is a much larger barrier than just having to solve this one problem on a per-system basis. I don't think Perry's asking you to solve this problem, BTW. :') |
From: William H. N. <wil...@ai...> - 2004-03-31 22:17:53
|
On Wed, Mar 31, 2004 at 04:53:33PM -0500, Perry E. Metzger wrote: > > Christophe Rhodes <cs...@ca...> writes: > >> The #ifdefs are simple and are found all over the rest of the file > >> anyway. Can I use them? > > > > Just a thought -- might it be better to > > > > (a) rename get_spinlock to get_sbcl_threads_spinlock (or something > > that definitely signals that it should only be used to resolve > > internal contention; not to interface with any other form of lock on > > the platform, and (or "or", if get_spinlock is already idiomatic for > > that) > > Dunno. Perhaps. I think the existing names are reasonable, though I > suspect that instead of rolling one's own threads, using the pthreads > interface from the operating system would be far superior. Then one > can simply use the various pthreads_mutex calls to do mutual > exclusion, and one gets access to the OS's thread scheduler > interfaces. > > That's a whole other story, though. Right now I just want to #ifdef > thread specific code in the non-threaded case. > > > (b) write a non-threaded version of get_spinlock() and > > release_spinlock() on the x86, such that the appropriate one will be > > chosen depending on LISP_FEATURE_SB_THREAD. Then the operation of > > get_spinlock() will be *word = value; or equivalent -- certainly > > cheaper than lock cmpxchg. > > There isn't any use in the code for spinlocks outside of thread > exclusion, so it isn't clear that we need a non-threaded version. Christophe's approach can end up being easier to maintain. Similarly, one could write copy_function_into_core(def, mem_area); bless_area_with_exec_permissions(mem_area); /* with a definition of bless_area_with_exec_permissions() which * turns into no-op on systems which don't need it */ or copy_function_into_core(def, mem_area); #if THIS_OS_NEEDS_BLESSING_BEFORE_EXECUTION bless_area_with_exec_permissions(mem_area); #endif or copy_function_into_core(def, mem_area); #if X86PLUS || NEW_LINUX || FROBBED_BSD || WINTHISTIMEFORSURE bless_area_with_exec_permissions(def, mem_area); #endif or copy_function_into_core(def, mem_area); #if X86PLUS expermit(mem_area->start, mem_area->end); #endif #if NEW_LINUX || FROBBED_BSD _pmn_fgs(mem_area->start, mem_area->end - mem_area->start, E_X); #endif #if WINTHISTIMEFORSURE NextPopupConfirmation(SUPPRESS); AntiVirusDeinvoke2(mem_area->end, mem_area->start, mem_area->start); #endif to express similar things, but I find the first seems to minimize pain. -- William Harold Newman <wil...@ai...> "There's nothing an agnostic can't do as long as he doesn't know whether he believes in anything or not." - Monty Python. PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Perry E. M. <pe...@pi...> - 2004-03-31 22:38:23
|
Daniel Barlow <da...@te...> writes: > "Perry E. Metzger" <pe...@pi...> writes: > >> Dunno. Perhaps. I think the existing names are reasonable, though I >> suspect that instead of rolling one's own threads, using the pthreads >> interface from the operating system would be far superior. Then one > > There are two reasons we don't use the pthreads interface > > (1) the 'LinuxThreads' implementation of pthreads as used in Linux 2.4 > is absolutely fucking awful, and screws up any program that > attempts to use signals for anything more complex than "duh, an > error happened, let's print a message and exit". As we use > signals for all kinds of stuff including a write barrier for the > GC, this was not an option. That's not the case on all other platforms. > (2) Accessing dynamically bound special variables requires > thread-local storage. Conceded that these tend to get used less > often than lexical variables, but even so, doing a foreign call > into C for every special variable access would (my gut feeling) be > so slow it wouldn't even qualify as a joke. Not to mention > involving interesting circularity issues with e.g. the way that > WITHOUT-INTERRUPTS works > > (1) really isn't a big deal any more (in fact we recommend linux 2.6 > for threaded sbcl anyway), but any pthreads-compatible sbcl is going > to have to work out how to cope with (2) sanely, and right now I don't > have the time. Generally speaking, the thread local storage is accessed in extremely simple ways. For example, on NetBSD, pthread_getspecific simply does: self = pthread__self(); return (self->pt_specific[key]); On most architectures, a register is reserved for the pthread pointer and the pthread__self call ends up being an inlined register access, so in the end, that whole call turns into nothing but a register relative access. On other platforms, it involves a little trickery and one or two more instructions. The compiler can, in all likelihood, do all that directly -- it is simple enough. There is no need to call out to C, or even to invoke a function. It has to be OS and platform specific but that isn't a giant issue. -- Perry E. Metzger pe...@pi... |
From: <da...@te...> - 2004-04-01 10:25:28
|
On Wed, Mar 31, 2004 at 05:38:17PM -0500, Perry E. Metzger wrote: > Generally speaking, the thread local storage is accessed in extremely > simple ways. [...] > The compiler can, in all likelihood, do all that directly -- it is > simple enough. There is no need to call out to C, or even to invoke a > function. It has to be OS and platform specific but that isn't a giant > issue. Yes, I have no problem with doing that, but it's clearly not "using the pthreads interface", it's "being compatible with the system's pthreads implementation". There are people out there who seem to believe that using pthreads would get us portable threading "for free", and I just want to be clear that this is not the case - at least, not for any usable threading implementation -dan |
From: Perry E. M. <pe...@pi...> - 2004-04-01 14:23:14
|
da...@te... writes: > On Wed, Mar 31, 2004 at 05:38:17PM -0500, Perry E. Metzger wrote: >> Generally speaking, the thread local storage is accessed in extremely >> simple ways. > [...] >> The compiler can, in all likelihood, do all that directly -- it is >> simple enough. There is no need to call out to C, or even to invoke a >> function. It has to be OS and platform specific but that isn't a giant >> issue. > > Yes, I have no problem with doing that, but it's clearly not "using the > pthreads interface", it's "being compatible with the system's pthreads > implementation". There are people out there who seem to believe that > using pthreads would get us portable threading "for free", and I just > want to be clear that this is not the case - at least, not for any > usable threading implementation Certainly. It is not free at all. On the other hand, you then don't need to rewrite the userland and kernel components of the thread engine, which are the really expensive and nasty portions of the job. In NetBSD, for instance, the scheduler activations implementation is a very large and macho chunk of code -- nothing one wants to do one's self if one can steal it. -- Perry E. Metzger pe...@pi... |
From: Andreas F. <as...@bo...> - 2004-04-01 23:18:25
|
On 2004-04-01, Perry E. Metzger <pe...@pi...> wrote: >> Yes, I have no problem with doing that, but it's clearly not "using >> the pthreads interface", it's "being compatible with the system's >> pthreads implementation". There are people out there who seem to >> believe that using pthreads would get us portable threading "for >> free", and I just want to be clear that this is not the case - at >> least, not for any usable threading implementation > > Certainly. It is not free at all. On the other hand, you then don't > need to rewrite the userland and kernel components of the thread > engine, which are the really expensive and nasty portions of the > job. Hm. You seem to be unfamiliar with the way SBCL does threading. I'll summarize what I know about it (from experience I gathered while failing to port sbcl/threads to freebsd): * SBCL's process interface is built on operating-system scheduled processes that share an address space. * SBCL handles a few things that a posix threading library is supposed to: - locks - queues - thread-local memory management (on x86, via the %fs register). * it handles things that a posix threading library doesn't: - cross-thread garbage collection - sane handling of signals (e.g. SIGALRM or the floating point exceptions that supposed to be delivered to the process that caused them) So, because we're using OS-scheduled processes for our threads, there's no need to port a scheduler in the runtime to other operating systems or architectures. What needs to be done to port sbcl/threads to a foreign architecture / operating system is, roughly, this: * find something that works like linux's clone(), i.e. something that creates a process sharing address space with the parent process, capable of receiving its own signals. For FreeBSD, that would be rfork. On NetBSD, I guess that would be fork1. On Solaris, probably thr_create. * find a way to reliably signal asynchronous events (e.g. "GC is due" or "my lock is no longer held") to other threads. On most reasonable platforms, that would be realtime signals. * abstract out the relevant parts of the runtime to be less linux-specific. * (only when porting to a non-x86 architecture): port gencgc, because it's the only GC we have that understands the concept of unmovable objects. * (only when porting to a non-x86 architecture): write VOPs for the locking semantics. * fix random things that break (like GC producing an infinity of segfaults) * stress-test the threading layer. At least, that was my schedule for porting threads to fBSD. I came as far as the second-to-last bullet point and then stopped because SBCL moved away from ptrace(2) to real-time signals, which are unimplemented in fBSD. For a pthread implementation, I estimate that there would be fewer steps required for a port to a new architecture/OS, but they would be more painful: * work around unspecified signal handling behavior that is arbitrarily implemented in the platform's threading library. * find a way to reliably signal asynchronous events (e.g. "GC is due" or "my lock is no longer held") to other threads. On most reasonable platforms, that would be realtime signals. * (only when porting to a non-x86 architecture): port gencgc * (only when porting to a non-x86 architecture): write VOPs for the locking semantics. * fix random things that break. * stress-test the threading layer. Either way, we're using non-standardized behavior of the OS (either by relying on OS-internal routines for process cloning or by working around unspecified signaling semantics). So, you're welcome to port sbcl/threads to pthreads, but it is going to be a painful exercise and the result is probably not going to be much better (in performance or portability terms) than what we have now. It would still be interesting to try it, though. Even if the port fails, there will be valuable lessons to be learned. And if it doesn't, SBCL has one more threading architecture. Yay! Good night, -- Andreas Fuchs, <as...@bo...>, as...@ja..., antifuchs |
From: <da...@te...> - 2004-04-02 10:20:41
|
Pretty fair summary: On Fri, Apr 02, 2004 at 01:18:18AM +0200, Andreas Fuchs wrote: > * find something that works like linux's clone(), i.e. something that > creates a process sharing address space with the parent process, > capable of receiving its own signals. For FreeBSD, that would be > rfork. On NetBSD, I guess that would be fork1. On Solaris, probably > thr_create. > * find a way to reliably signal asynchronous events (e.g. "GC is due" > or "my lock is no longer held") to other threads. On most > reasonable platforms, that would be realtime signals. On Linux we can use the futex() calls for locking. I don't know of any other system that has an equivalent, which is a shame as they're really pretty neat > * abstract out the relevant parts of the runtime to be less > linux-specific. > * (only when porting to a non-x86 architecture): port gencgc, because > it's the only GC we have that understands the concept of unmovable > objects. Unmovable objects nice, but the real reason for gencgc is the support for allocation regions: this means that multiple threads can allocate at once without having to lock the allocator. > * (only when porting to a non-x86 architecture): write VOPs for > the locking semantics. * and VOPs for special variable access to use whatever TLS scheme is appropriate for the platform (%fs, %gs, offset from a general- purpose register, or whatever) > Either way, we're using non-standardized behavior of the OS (either by > relying on OS-internal routines for process cloning or by working > around unspecified signaling semantics). God bless you, Mr Posix. -dan |
From: Perry E. M. <pe...@pi...> - 2004-04-02 19:17:11
|
Andreas Fuchs <as...@bo...> writes: > On 2004-04-01, Perry E. Metzger <pe...@pi...> wrote: >>> Yes, I have no problem with doing that, but it's clearly not "using >>> the pthreads interface", it's "being compatible with the system's >>> pthreads implementation". There are people out there who seem to >>> believe that using pthreads would get us portable threading "for >>> free", and I just want to be clear that this is not the case - at >>> least, not for any usable threading implementation >> >> Certainly. It is not free at all. On the other hand, you then don't >> need to rewrite the userland and kernel components of the thread >> engine, which are the really expensive and nasty portions of the >> job. > > Hm. You seem to be unfamiliar with the way SBCL does threading. I'll > summarize what I know about it (from experience I gathered while > failing to port sbcl/threads to freebsd): > > * SBCL's process interface is built on operating-system scheduled > processes that share an address space. On most operating systems, these will be normal threads. "clone" is a linuxism, and I'm not even sure it is the heart of the new pthreads implementation. > * SBCL handles a few things that a posix threading library is > supposed to: > - locks > - queues > - thread-local memory management (on x86, via the %fs register). The kernel assists with many of those things on many platforms. On some OSes, the use of a multilevel scheduler also means that if a thread blocks in a system call, userland has to take an upcall in order to schedule the proper thread for execution. That means you have to re-write the userland part of the multi-level scheduler if you don't use the one written in C. I suggest doing a search for "scheduler activations" etc. to learn about this sort of thing. > * it handles things that a posix threading library doesn't: > - cross-thread garbage collection That has to be handle in userland, yes. > - sane handling of signals (e.g. SIGALRM or the floating point > exceptions that supposed to be delivered to the process that > caused them) That actually depends on many platforms on the kernel interfaces for the threading system as well. The trap occurs during the execution of of the thread, falls into the kernel, etc. > So, because we're using OS-scheduled processes for our threads, Again, that's very linux specific. (Well, you could do things similarly on plan 9 as well I suppose, but...) You really don't want to do things this way. You'll end up performing way worse than native threads on most platforms. Even newer linux threads are unlikely to be clone() based in the future. FYI, one of the reasons you note so many problems with old linux pthreads handling signals right (POSIX does specify the behavior -- linux simply violates POSIX) is that it does threads with clone(). > For a pthread implementation, I estimate that there would be fewer > steps required for a port to a new architecture/OS, but they would be > more painful: > > * work around unspecified signal handling behavior that is > arbitrarily implemented in the platform's threading library. Actually, that's not the layer it is implemented at except in a pure userland implementation. > * find a way to reliably signal asynchronous events (e.g. "GC is due" > or "my lock is no longer held") to other threads. On most > reasonable platforms, that would be realtime signals. No, you use condition variables and locks etc. in all likelyhood. > Either way, we're using non-standardized behavior of the OS (either by > relying on OS-internal routines for process cloning or by working > around unspecified signaling semantics). Actually, really you just need to use the pthread layer except you want to avoid a foreign function call to the pthread library for every access to thread local storage... > So, you're welcome to port sbcl/threads to pthreads, but it is going > to be a painful exercise and the result is probably not going to be > much better (in performance or portability terms) than what we have > now. I tend to disagree, but there's another reason I'm unlikely to do it, which is I rabidly hate threads and do not like programming in them, so since this doesn't "scratch my itch" I'm not likely to want to work on it myself... :) -- Perry E. Metzger pe...@pi... |
From: Daniel B. <da...@te...> - 2004-03-31 22:18:16
|
"Perry E. Metzger" <pe...@pi...> writes: >> The intention (and I haven't checked to see if this is really the >> case) was that the functions getting and releasing spinlocks would be >> declared static inline and therefore a reasonably smart compiler (as [...] > They can't. > > First, the C compiler doesn't know if you have access to a thread > library or not, and even if it did, it wouldn't know that the contents > are meaningless in a non-threaded program. I think I can see how we're talking at cross-purposes here. My recollection was that foo-arch.h defined alternative do-nearly-nothing versions of get_spinlock and release_spinlock when LISP_FEATURE_SB_THREAD is not defined. This turns out, now I look at the code, not to be the case. I'd rather that it be made the case than that every call to {get,release}_spinlock get surrounded by ifdef. -dan -- "please make sure that the person is your friend before you confirm" |
From: Neil S. <na...@ar...> - 2004-04-02 21:15:35
|
On Fri, Apr 02, 2004 at 02:17:05PM -0500, Perry E. Metzger wrote: > "clone" is a linuxism, and I'm not even sure it is the heart of > the new pthreads implementation. It does and I'm pretty sure it will continue to be that way. > I tend to disagree, but there's another reason I'm unlikely to do it, > which is I rabidly hate threads and do not like programming in them, > so since this doesn't "scratch my itch" I'm not likely to want to work > on it myself... :) I share your hatred. At first they look attractive. Then you have to deal with all the secondary problems that arise from their use. Unmaintainability seems to be the typical end result. All, IMHO, of course. Give me easy, fast interprocess communication any day. Neil |
From: Perry E. M. <pe...@pi...> - 2004-04-02 21:59:58
|
Neil Schemenauer <na...@ar...> writes: > On Fri, Apr 02, 2004 at 02:17:05PM -0500, Perry E. Metzger wrote: >> "clone" is a linuxism, and I'm not even sure it is the heart of >> the new pthreads implementation. > > It does and I'm pretty sure it will continue to be that way. I just looked. The NPTL paper claims they extended clone pretty extensively -- I'm not surprised that they had to, since the old mechanism wasn't up to it. >> I tend to disagree, but there's another reason I'm unlikely to do it, >> which is I rabidly hate threads and do not like programming in them, >> so since this doesn't "scratch my itch" I'm not likely to want to work >> on it myself... :) > > I share your hatred. At first they look attractive. Then you have > to deal with all the secondary problems that arise from their use. > Unmaintainability seems to be the typical end result. All, IMHO, of > course. > > Give me easy, fast interprocess communication any day. That and event driven programming, especially since events are very natural in a lisp environment. -- Perry E. Metzger pe...@pi... |
From: Perry E. M. <pe...@pi...> - 2004-04-02 22:08:14
|
"Perry E. Metzger" <pe...@pi...> writes: > Neil Schemenauer <na...@ar...> writes: >> On Fri, Apr 02, 2004 at 02:17:05PM -0500, Perry E. Metzger wrote: >>> "clone" is a linuxism, and I'm not even sure it is the heart of >>> the new pthreads implementation. >> >> It does and I'm pretty sure it will continue to be that way. > > I just looked. The NPTL paper claims they extended clone pretty > extensively -- I'm not surprised that they had to, since the old > mechanism wasn't up to it. Not to mention that they changed the semantics of a bunch of other calls so that clone() based threads would work properly with POSIX semantics... Perry |