apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: cvs commit: apr-util/buckets apr_buckets_socket.c
Date Wed, 10 Oct 2001 19:28:45 GMT

[I started writing this hours ago and got sidetracked... I think this
issue is already settled since then but I'll finish my thought anyway.]

On Wed, 10 Oct 2001, Justin Erenkrantz wrote:

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

Yes.  That's correct.  EAGAIN could at any time be returned from a read of
any bucket type _if you do a nonblocking read_.  EAGAIN should never be
returned if you do a blocking read.  Basically, SUCCESS means "I got some
data for you" or "the bucket is empty".  In either case, SUCCESS means
"move on to the next bucket, nothing else to see here."

For nonblocking reads, it is understood that there is a special case: you
might be able to read more later but just don't have it available right
now.  That's a separate return code, the standard for which is EAGAIN.
It tells the caller the bucket is empty _right now_, but not to move on to
the next bucket because we'll have something for them later.

Now, that's not to say that ALL possible return values from socket reads
and the like should be returned directly by the buckets.  APR_EOF is a
good example.  That's something that just doesn't make sense from the
point of view of reading a bucket--it's information that the buckets code
can use internally but that it should hide from the caller.

I thought we had already documented that EAGAIN or SUCCESS could be
returned for nonblocking reads, but if we haven't, then yes, it definitely
needs to be done.

Thanks for the patches to revert this and fix the core, btw.


   Cliff Woolley
   Charlottesville, VA

View raw message