httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <>
Subject Re: [VOTE] AP vs APR prefix change in Apache...
Date Fri, 09 Jul 1999 16:17:01 GMT

In article <> you wrote:
> Dean Gaudet wrote:
>> On Thu, 8 Jul 1999, Michael H. Voase wrote:
> [...]
>> APR doesn't provide threading per-se, it relies on there being an
>> underlying thread implementation... such as pth.  It's complementary --
>> APR just provides us with an abstraction to the thread interfaces so that
>> we can write code which has no idea what the underlying thread interface
>> is.
>   Pth is one of the reasons I started looking
> at this api mapping method . The issue that gets at me
> is that pth wont provide any benefit to SMP boxen . Once
> the scheduler starts , your stuck on one proccessor . 

Sure, Pth cannot provide this.

>   If you guys are going to put pth in apr then

Errr.... wait! I both think nobody will put Pth into APR (see the license
discussions ;) and that you misunderstood Dean here. What Dean meant was that
Pth can be _one_ of the backend threading libs for APR. But not the _primary_
threading lib for APR, of course.

> it will be impossible to use pth on mutliprocessor 
> boxen ( theres a chicken and egg scenario here , hard
> wire the pth functions into apr and you wont be able 
> to use the api until pth_init has been called . Call
> pth_init and youre glued to the processor . SOL )

Sure. But as explained: One should not hard-code Pth references into APR. Pth
should be just one possible threading lib for APR and it should be threated
more like a _fallback_ pthread library in case the vendor doesn't provide (a
SMP aware!) pthread library. So I don't think we're talking about a problem

>   However , if the api mapping is set such that
> it switches in the pth posix replacement functions when
> the pth scheduler is started then maybe , just maybe ,
> it might be possible to launch multiple seperate
> schedulers on an SMP box . It would cost an extra flag
> check on each and every posix replacement function call .
> Considering that all of these calls are blocking calls,
> the cost of the wrapper is insignificant in comparison
> to the cost of the calls themselves ...
> ( well maybe not usleep , but that is not a heavilly
> used call ... ;)

Yes, such a dispatching would be possible.  But I've to admit that currently I
see no real reason why APR should switch on-the-fly between the threading
libs. At least I'm sure it doesn't work with all pthread libs out there,
because they do lots of tricks internally ;)

Instead what is more reasonable to allow APR to be linked against a vendor
pthread and Pth in native mode. And let the application on startup (perhaps
even after a few forks) decide which library to use. But switching later I
think might not work with all libs and there is perhaps not even a good reason
for this, isn't it?
                                       Ralf S. Engelschall

View raw message