---Ben Laurie [mailto:[EMAIL PROTECTED]] said:
> Certainly in the case of a socket, a blocking read will _not_ return
> APR_EOF (this was my original complaint!). So I'm not sure what you mean
> by this.
<shrug> I think we're just confusing the issue by saying basically the same
things in different ways.
>> That might be. I'd personally argue that they're both success
>> cases... you've read as much as there is to read from this bucket.
>> Move on to the next bucket.
> Exactly.
I guess I was confused about which direction you wanted us to move. I thought
you wanted APR_EOF returned in both cases. Do we agree, then, that the only way
to make it work is to return an empty bucket with APR_SUCCESS, regardless of
blocking mode?
> So what should happen in _this_ case is that the pipe
> bucket should be deleted from the brigade. Hmm. And then you end up with
> the possibility of having no bucket. OK, I begin to see the logic, but I
> still don't like it: you return a zero length bucket simply because you
> have to return something.
But unfortunately, as you pointed out, it's bogus to delete the bucket from the
brigade while the caller still has a reference to it that it needs to get to the
next bucket. That had crossed my mind, but I didn't think it all the way
through. Removing the bucket from the brigade would be okay, because the
bucket's next pointer would still point back into the brigade at the right spot.
But then we'd have a bucket that floated off into space and never got destroyed.
Bummer.
> It makes just as much sense to me to
> return no bucket at all and an error code (even if its something other
> that EOF), and its more efficient.
I agree that it would be more efficient, but I don't think it's an error. The
bucket is empty, big deal. And returning no bucket would be even worse for the
caller, because the caller has to know that its bucket might disappear out from
under it before it has a chance to grab a pointer to the next bucket in the
brigade. But it can't grab that pointer BEFORE calling apr_bucket_read(),
either, because several buckets (like this one) insert another bucket after the
current one during the read.
So you're right, morphing into a zero-length bucket of another type is the only
way to make it work, kludgey as it is. We could use a lighter-weight
zero-length bucket--maybe an immortal bucket with an empty string "" in it.
That's just an optimization to save a few malloc calls, of course, but it might
be worth it.
<shrug>
--Cliff
