Jeff Trawick wrote:
>
> Ben Laurie <[EMAIL PROTECTED]> writes:
>
> > the end of socket_read (in apr-util/buckets/apr_buckets_socket.c) looks
> > like this:
> >
> > if (*len > 0) {
> > b = apr_bucket_socket_create(p);
> > APR_BUCKET_INSERT_AFTER(a, b);
> > }
> > else if (rv == APR_EOF && block == APR_NONBLOCK_READ) {
> > return APR_EOF;
> > }
> > return APR_SUCCESS;
> > }
> >
> > why the test for APR_NONBLOCK_READ? Surely an EOF is an EOF, whatever
> > mode you are in? Shouldn't it just return APR_EOF if rv == APR_EOF,
> > regardless of mode?
>
> It is simplest if the normal blocking read looks to the caller like an
> empty bucket; all the caller needs to know is that no error occurred
> and there are no bytes in the bucket; caller doesn't care if it is
> some sort of in-memory bucket or socket or pipe or whatever.
But the caller typically _does_ care if its EOF, so I don't see why this
is a win - if it doesn't do that, then I have to add this to mod_tls:
if(ret == APR_SUCCESS && len == 0 && eReadType == APR_BLOCK_READ)
ret=APR_EOF;
which strikes me as absurd!
Hmm. I suppose I then have to insert a 0 length bucket into the outgoing
brigade if we're blocking, in order to be consistent. That's crazy,
isn't it? Am I missing something?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
