Stas Bekman <[EMAIL PROTECTED]> writes:
> Joe Schaefer wrote:
> > Stas Bekman <[EMAIL PROTECTED]> writes:
> >
> >>Now going to try and reduce that sequence to a shorter one...
> > I don't think you need bother- the brigade loop is miscoded in compat.pm's
> > content sub- you can't ask for the next bucket *after* $b has been
> > removed.
>
> why not? it still points to the next bucket, no?
Probably so, because of the way (I think) APR_RING_UNSPLICE is
currently implemeted. But IMO that's not guaranteed by the
apr_ring.h documentation (unless that's what is meant by
"dangling pointers").
>
> > Instead of iterating using for(;;), use while():
> > while ($b = $bb->first) {
> > ++$seen_eos, last if $b->is_eos;
> > if ($b->read(my $buf)) {
> > $data .= $buf;
> > }
> > $b->delete; # APR::Bucket needs to wrap apr_bucket_delete(),
> > # since APR_BUCKET_REMOVE() doesn't actually
> > # decrement the bucket refcount
> > # so the bucket allocator can reclaim $b
> > }
>
> I've been explicitly rewriting the iteration loops recently not to use the
> while loop, because for anything more complicated it becomes a mess and too
> easy to put $b->delete in the wrong place.
OK, but don't call $b->remove, because its not doing anything
useful. Leave the buckets in the brigade and call $bb->cleanup
after each inner for() loop, that way the next call to get_brigade
will be able to reuse those buckets (if at all possible).
> I wonder why don't I see the problem right away then, and only after
> running a bunch of other tests. Any idea why?
No clue, yet.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
