On Sunday 07 May 2006 23:07, Garrett Rooney wrote: > On 5/7/06, Nick Kew <[EMAIL PROTECTED]> wrote: > > Now, what about a platform that HAS_PTHREAD_KILL, but which uses some > > other form of threading in its APR (isn't that at least an option on some > > FreeBSD versions?) Wouldn't this break horribly when it pthread_kills a > > non-pthread? Couldn't it even happen on Linux, in principle at least? > > On FreeBSD you basically need to pick one threading library, if you're > linked against more than one of them bad things happen, since they all > implement the same pthread functions.
So there's no thread API that isn't pthreads? > On Solaris, which does have > multiple threading implementations with different APIs, I don't think > it would matter, since pthreads is implemented on top of the lower > level solaris threads. But if an APR was built on the lower-level threads, then we might be pthread_kill()ing something that isn't a pthread? Even if it's only a theoretical possibility, we should avoid it. If we had an APR #define for pthread vs non-pthread threading implementations, we should test that. As it stands, if we take the patch as-is, then IMO we need to document the MPMs explicitly as requiring APR threads to be built on pthreads. > I suspect that's the common case, if there is > another threading library it's lower level and pthreads is generally > implemented on top of it. The only other case I can think of is if > you're using a user level threading library but the system has its own > pthreads library. Exactly. What if someone out there has a super-optimised APR built on their lower-level threads, on a platform that also has pthreads? -- Nick Kew
