httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: [PATCH 5/6] hard restart on Linux #38737
Date Sun, 07 May 2006 23:01:35 GMT
On Sunday 07 May 2006 23:07, Garrett Rooney wrote:
> On 5/7/06, Nick Kew <nick@webthing.com> 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

Mime
View raw message