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 20:10:15 GMT

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

> I would have done better if the relevant manuals were to hand,
> and not buried under hundreds of pounds of flower pots.  (Not
> that the manuals are especially good fertiliser.. :-)

Worse than grass clippings.

> > My style of design assumes that there is always an "object
> > model" implicit in everything.  It continues to elude my
> > thick skull what "object" the context is standing for.
> > It would seem to be standing in for a fuzzy union of
> > activity/thread/pool/thread-state and globals.
> 
> Mmm, how about the Object class in Java? :->

Ah, now that's another hypothisis about what the context object is
trying to be.  The root class of APR's object system.  That's what I
thought at first actually.  Is that what your trying to get here.  I
almost of agree with that.  This would imply that all objects created
by APR have a pool, and a slot for user properties, i've no problem
with that.

> > 2. What compelling advantage is worth the cost of
> >    passing an additional parameter to every function?
> 
> Uniformity of syntax, and complete freedom for all functions
> to call whatever else is necessary to get their jobs done.
> This allows routines in the call chain to pass it down, and
> those that need it can use it, and those that don't can
> ignore it (but propagate it).  I have an hypothetical example
> in mind, if it comes to that.

I understand that is what will happen, it's just that I want
to be convinced that this bucket brigade of parameter passing
is buying me something I need.

> > 3. Do pools need to block signals?  If so, do they
> >    need a pointer to the thread they reside in?
> 
> If you mean do pool operations need to be signal-safe, I think
> the answer is yes.  They need to be able to achieve that
> signal-safety in a stackable and modular way.

Would you rather write:
      ap_palloc(cntx, p, sizeof(foo))
   or ap_palloc(p, sizeof(foo))   
for the next decade?

I'm a conservative traditionalises here.
What's this radical cool cntx doing for me that means I have
to change from what works?

>    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.

 - ben

Mime
View raw message