httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <bh...@pobox.com>
Subject Re: Pools not adequeately protected by mutexes?
Date Thu, 29 Apr 1999 19:50:53 GMT
Rodent of Unusual Size <Ken.Coar@Golux.Com> writes:

> Ben Hyde wrote:
> > 
> > No no no!  The pool API is designed with the presumption that operations
> > on a single pool are done only by a single thread.  If two threads wish
> > to share a pool they must mux their accesses.
> 
> An admirable sentiment, but has anyone performed an analysis
> to make sure we're actually doing that in all cases?
> Such as never passing pconf or pchild or any other
> process-wide pools as work areas to any routines running
> in a thread?  The specific snippet Manoj quoted involves
> adding a cleanup, which is something that I wouldn't be
> surprised to find done (and assumed to be legal) against
> some such pools..

Any allocation of memory has this problem, not just cleanups.

I spent a lot of time scratching my head and reading the code
while Dean and I first had this dicussion.  

pchild is local to http_main so it's easy to review
(except for it's bogus appearance as both a static global
and a local in there).  If we ever get around to having
a per-thread data structure it should have a pool for
the thread's pleasure.

The pconf is also static in there which is a help in
tracing out it's uses.  It's not a huge help since it
travels around a lot.  What would have to happen is
for it to be stored during configuation time and then
allocated in during request processing time.  Oviously
that would be likely to leak.  A clever module author
might think it was safe to allocate in that pool during
request processing, but he'd be wrong.  The reason
he'd want to do that is a vain attempt to allocate
memory from one request for use by another later
request.  Of course everybody thinks they want to do
that, but in Apache most all attempts along those lines
fall apart becasue the second request is in another 
process.

 - ben

Mime
View raw message