httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: socket_read?
Date Sun, 18 Feb 2001 02:01:53 GMT
Jeff Trawick wrote:
> Ben Laurie <> writes:
> > But the caller typically _does_ care if its EOF,
> if you're talking about filters, I would contend that the caller
> typically cares about eos, not EOF
> eos is the bucket brigade equivalent to EOF in traditional file
> reading

Then (as I suspected a moment ago in another reply) socket_read is

> an EOF condition on the underlying read operation of a particular
> bucket may or may not mean that it is the end of the brigade for the
> filter to process
> >                                         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!
> I'm not sure what you're trying to accomplish.  Are you an input
> filter?  Is the end of the connection?  Add an eos bucket to what you
> return to the caller.  Is there simply no data available from the
> client yet?  Return the brigade you have so far.

Source will be checked in shortly - then you'll see what I'm doing.

> > 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?
> I probably don't understand the situation, and you've probably hit a
> situation that is different than other filters have encountered thus
> far.  Different stuff happens at source and sink, and you are both I
> suspect.

Not only am I both, but I have to do both when the higher layers think
I'm only doing one :-) It's really hurting my head! (Though I think I've
got it under control now)




"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

View raw message