Stas Bekman <[EMAIL PROTECTED]> writes:

> Joe Schaefer wrote:
> > Stas Bekman <[EMAIL PROTECTED]> writes:
> > [...]
> >
> > > I like the idea of bb, but you will need to explicitly destroy it as
> > > well.. .
> > Not sure I believe that...
> 
> You mean all the calls to $bb->destroy are useless and even wrong?

IMO they should probably be replaced with $bb->cleanup.  Actually invoking
$bb->destroy is almost always a mistake right now (even though win32
reportedly has problems with that)...
 
[...]

> > I don't see the point of an APR::Brigade::DESTROY.  What users need to know
> > about brigades is
> >   1) if they invoke $bb->destroy themselves, they become responsible
> >      for cleaning up any future buckets added to that brigade,
> 
> Ah, shouldn't that be $bb->cleanup? If you destroy $bb, how can you
> add any new buckets to it?

Not quite.  Right now all $bb->destroy does is run the pool cleanup that
destroys its buckets, and then removes that pool cleanup.  At one point
the idea of allocating the brigade struct from the bucket allocator was 
tossed around, which would have made $bb->destroy wipe out the brigade 
struct as well  (thus invalidating the C pointer).  That change hasn't 
happened, yet, so the brigade struct is allocated from the pool.

> >   2) if they feed a brigade to ap_pass_brigade, according to the
> >      ap_pass_brigade docs, they should not touch that brigade object
> >      ever again.  Even calling destroy() isn't documented as being
> >      safe. 
> 
> yes, that's certain.
> 
> > Trying to simplify some of this mess for modperl filter authors,
> > perhaps with a smart DESTROY sub, will add lots of complexity to
> > APR__Brigade.h - similar to what's in APR__Pool.h now.
> 
> That's exactly what I was thinking about. Though I can see other
> applications for your recent work on APR::Pool. For example we need
> this kind of protection for $r and other major objects. If people get
> $r into a closure, they have a guaranteed segfault on the next
> request, which is usually very hard to trace. The SVMAGIC protection
> will allow us to croak when someone writes a closure instead of segfault.

That would be a nice thing to do.

-- 
Joe Schaefer


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to