Callback after close
Zhen
I have a question for you.
As you all probably know, the close callback is called after (or
during) execute.
Right now, if 2 connected wvstreams (via any means, such as tcp, unix
socket, ...) is disconnected, isok() will return true until you try to
read from the stream. When you do, close will be called.
The question is, y is this the case?
Was this a design decision, or a bug? (Or something unfixable?)
It would be very nice is isok() returns false as soon as the
connection is broken, since right now you have to deal with the
possibility that the connection is already dead in execute/callback.
Thanks
Zhen
Avery Pennarun
> Right now, if 2 connected wvstreams (via any means, such as tcp, unix
> socket, ...) is disconnected, isok() will return true until you try to
> read from the stream. When you do, close will be called.
>
> The question is, y is this the case?
> Was this a design decision, or a bug? (Or something unfixable?)
>
> It would be very nice is isok() returns false as soon as the
> connection is broken, since right now you have to deal with the
> possibility that the connection is already dead in execute/callback.
Basically we did it this way because it's the standard behaviour of
Unix sockets (and it's easy to fake that behaviour on other OSes like
Windows).
And the reason *they* did it this way is actually a good one. Imagine
the following situation:
- Client initiates connection
- Server accepts connection
- Client sends request
- Server sends answer and calls close().
- Client reads answer, then close()s automatically at the end of the input.
That's a typical HTTP/1.0 request cycle. Everything's simple up until
the server has *sent* all the data and closed, but the client hasn't
yet *read* all the data. (There's no way in TCP for the server to
know if the client has read all the data yet.) If the client were to
deliver the closecallback() right away, the client would get cut off
before it was done reading all the data! Not useful.
Think of the close() as an event that's *part of the data stream*.
You don't want to receive it until you've read everything that comes
before it. And you might want to consider it explicitly as part of
reading your data stream.
Note that WvStream behaviour is designed explicitly so you *don't*
have to check isok() if you don't want to, most of the time. If the
stream is !isok(), read() will just return 0 bytes immediately. This
is the same as if the connection was still open but with no data
available, so you can just handle it the same way in your program.
There's not *strictly* any reason to call isok() in your execute()
function, unless you're looping and want to make sure you break the
loop at the right time... and you should break loops whenever read()
returns 0 anyhow.
Also note that the closecallback() is actually pretty rarely
necessary. I prefer to handle closing events in my read callback
whenever possible.
...
So to summarize: it may seem counterintuitive at first, but actually
this behaviour is exactly what you want when writing network
applications.
Have fun,
Avery