apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: cvs commit: apr-util/buckets apr_buckets_socket.c
Date Wed, 10 Oct 2001 14:55:47 GMT
On Wed, Oct 10, 2001 at 06:59:32AM -0700, Ryan Bloom wrote:
> 	do
> 	    do stuff so that we don't wait until there is data before
> 	    we process what we have now.
> 	while (apr_bucket_read == APR_EAGAIN)
> to:
> 	do
> 	    do stuff just like above
> 	whild (apr_bucket_read == APR_SUCCESS &&
> 		APR_BUCKET_FIRST()->length == 0)
> Libraries should return errors, because they are valid information that the
> caller can use.  They also do not break the abstraction, because we have
> essentially said that all bucket _can_ return EAGAIN, although anybody who
> looks at the code will realize quickly that only socket and pipe bucket ever
> _will_ return EAGAIN.

See, I think that's my complaint.  Now, we have to always handle
EAGAIN in every case where we read the buckets to be correct to the
abstraction.  Something just seems wrong about having to add this for
a special case where we could reasonably dictate how to handle it
in the special case.

I have a feeling that rather than fixing this, we're just going to
ditch the socket bucket entirely (what you and Greg have suggested).
And, I'd rather not do that because it means that the socket bucket
isn't doing what we want.  And, if it isn't doing what we want, I
think we need to stop and ask why.

I think in the example of CORE_IN, it would just completely ignore 
EAGAIN and return a 0-length brigade.  In my mind, that just seems 
the only rational decision to make there (perhaps not in the general
case).  The core filters should not be doing anything to slow down

But, I'm not sure how any reader of the buckets will know to do a
select/poll/etc *without* violating the knowledge that the bucket
is a socket-based bucket.  Then, it'd also have to retrieve the
socket from the bucket and then do a select/poll/etc on it.  And,
you'd have to handle the pipe case differently as well.  I guess
I see the violation occurring when the caller tries to "resolve"
the EAGAIN not with the EAGAIN itself.  The only way the caller 
can do that (from my understanding) is to know what the storage 
type is.  And, that's verboten, IMHO.

> Don't call a function from within a macro.  You have no way of knowing how
> often that function will be called.  Yes, I know it is done other places in the
> code, those are incorrect too.

Yeah, well, I just copied that code from a few lines below, but 
yeah.  =)  -- justin

View raw message