httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Garrett Rooney" <>
Subject Re: [PATCH 5/6] hard restart on Linux #38737
Date Mon, 08 May 2006 01:29:59 GMT
On 5/7/06, Nick Kew <> wrote:
> On Sunday 07 May 2006 23:07, Garrett Rooney wrote:
> > On 5/7/06, Nick Kew <> 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).


View raw message