Jeff Trawick wrote:
>
> Ben Laurie <[EMAIL PROTECTED]> 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
broken.
> 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)
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
