httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: thread locking within apr file io
Date Thu, 26 Apr 2001 12:38:19 GMT

> On Wed, 25 Apr 2001, Roy T. Fielding wrote:
>
> > APR file io, when compiled with APR_HAS_THREADS (the default unless it
> > is specifically disabled or on a non-thread platform), is acquiring
> > mutex locks on every buffered file read or write.  That is lunacy.
> > Whether or not locking is necessary must be decided by the caller,
> > not by the library.  The normal behavior is for buffers to be
> > thread-specific, and thus never need mutexing.
> >
> > BTW, the same can be said for pools -- right now it is locking all
> > pool operations, even though the only ones that need locking are those
> > shared by multiple threads (the global pools).  Bogus.
> >
> > This stuff came up while Justin and Aaron were performance testing
> > mod_mbox -- right now you can double the requests per second simply
> > by recompiling with --disable-threads.

Wow, which MPM are you using? That is actually quite a suprise to me as Apache 2.0 performance
is
close to that of Apache 1.3 (on AIX at least) which does not use pool  locking or buffer locking
for
file i/o.

>
> Well, that's a pretty major bump.  This makes complete sense to me.  I say
> let's remove the locks.  Make the application lock the code itself, which
> makes a bit more sense to me.
>
> The thread locks in the pools came from the Windows pool code, I would
> love to see those locks go away ASAP.
>
> Ryan
>

We need -some- pool locking. For instance, all the threads allocate subpools out of a pool
common to
the process the threads are running in.  It would be easy enough to mutex those cases (all
of which
are in the MPM I believe).

Bill



Mime
View raw message