<div class="gmail_quote">On Thu, Nov 12, 2009 at 10:00 PM, Matt McCutchen <span dir="ltr"><<a href="mailto:matt@mattmccutchen.net">matt@mattmccutchen.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
My point is that it's a clunky way to achieve the goal, and it would be simpler for the sender to just keep reading after a write error.<font color="#888888"><br>
</font></blockquote></div><br>Yeah, that's a good idiom, and the latest code wasn't doing a good enough job of that when the socket closed. One new issue turned out to be that the client started getting a read error (where the old code would get a write error) due to the buffer-filling code getting an EOF on the socket (even though the perform_io() call was ostensibly there to try to write some data). There was also a bug where an EOF error did not try to empty out any message data currenly in the buffer.<br clear="all">
<br>I've committed some improvements for this, so the error reporting should be better when talking to older versions. For instance, the input code now just notes an input EOF unless it is there to read some data and the data is not present. It also does a better job of draining any pending error messages from the input buffer (and reading any final messages) when a write error occurs.<br>
<br>As for the arbitrary io_timeout that gets set, yes, it is debatable if it is a good idea. While not strictly necessary, I kind of like having it just as a final sanity check for the error-exit code. I did make the arbitrary timeout larger, though, since it should not ever really be needed. I'll also review the error-handling a bit more, and possibly reconsider this further.<br>
<br>..wayne..<br>