httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <bh...@pobox.com>
Subject Re: Context types in APR.
Date Fri, 07 May 1999 21:02:50 GMT

Rodent of Unusual Size <Ken.Coar@Golux.Com> writes:

> Ben Hyde wrote:
> > 
> >                             This would imply that all objects created
> > by APR have a pool, and a slot for user properties, i've no problem
> > with that.
> 
> I like that.

> > Would you rather write:
> >       ap_palloc(cntx, p, sizeof(foo))
> >    or ap_palloc(p, sizeof(foo))
> > for the next decade?
> 
> I'd rather call ap_palloc(cntx, sizeof(foo)).  I've been labouring
> under the assumption that it was clear that a context includes
> a pool.

Now were getting someplace.  If your willing to spell cntx "p"
maybe we've agreed. :-).

> > >    I fail to see
> > > why pools *must* be associated with one and only one thread;
> > > I maintain that they are separate, not subordinate.
> > 
> > To avoid having ap_palloc pay the cost of getting a lock on
> > every allocation.  So they have to "reside" in a thread by
> > default.
> 
> Feh.  If you have a pool subordinate to a thread object,
> note the fact that synchronisation isn't necessary.  Store
> that note in either the pool structure or the context structure
> when it's created.  (Hey, that's not a bad idea in general..)
> For pools that aren't 'part of' a thread, leave the bit clear.

This is the classic end to end issue.  At what layer in the
onion is the multiplexing done?  It doesn't belong in the pool
it belongs on the data structure being shared.  If you put it
on the pool, then you still have to put it on the shared data
structure and then each operation on the on the data structure
has to take the data structure lock, and then as it falls into
the pool it takes the pool lock.  A pool lock is entirely
redundent - a waste.

 - ben

Mime
View raw message