apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "'Justin Erenkrantz'" <jerenkra...@ebuilt.com>
Subject Re: Pools & locking?
Date Fri, 18 May 2001 00:43:58 GMT
On Thu, May 17, 2001 at 05:13:33PM -0700, Ian Holsman wrote:
> so If I understand this thread correctly
> we could removing the locking code from the allocation routines
> (for use in running apache2.0 ) without any penalty?
> as we are using thread based pools ????
> maybe this can be a config option on the apr configure script (--disable-Memory-Pool-Locking
> ..Ian
> (I know I could just wait for the SMS stuff to get fully implemented, but
> Im thinking we could fix it now, and later on remove the config option when
> SMS is fully integrated)

Well, it's a two-pronged problem:

1) httpd-2.0 has thread-local request pools, so locking in a pool that
is by its very nature independent doesn't get you much and just serves 
to slow you down.  How big of a slow down, I'm not sure.  I seem to 
remember when I did my initial analysis it was quite noticable - but 
that doesn't mean too much.

2) However, APR is generic - removing the locks for threaded allocation
could cause problems.  If Subversion has threads, but has one global pool, 
race conditions will be now introduced (don't know if that is the case).  
That's much worse than the speed penalty introduced by doing too many

As Roy mentioned, there are some things that can be done with hierarchical 
allocators to fix this problem - ones that will specifically know whether 
a lock should be held or not.  My guess is a new apr_sms_nolock_t would
indicate that no locking should be done even if threads are present.
However, this requires the pool stuff to be converted to apr_sms_t
semantics first, and the request_rec (or connection's pool - not sure
which one makes sense here) would be switched to apr_sms_nolock_t.
(Just one suggestion - sure there are other ways to do this...)

I'm muddling through the apr_uri stuff at the moment (moving it to
apr-util), so I'm not sure if/when I can get to it.  -- justin

View raw message