On 5/7/06, Nick Kew <[EMAIL PROTECTED]> wrote:
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?
Correct, there are user level pthreads implementations (libc_r, GNU
pth), and kernel or mixed userland/kernel implementations (libpthread,
libthread), but they all expose the same pthreads API, and you can't
mix them.
> 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.
Does APR actually do this on any platform?
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?
Well, if they do then it's not in the actual APR distribution, so I
have trouble caring... If we're on unix systems, I think it's safe to
assume that it's either pthreads, or something that interoperates well
with pthreads (i.e. solaris threads, where you can use either the
pthreads functions or the solaris threads functions and they play
reasonably nicely together).
-garrett
