On Thu, Jul 19, 2012 at 04:18:33PM +0800, Daniel Veillard wrote:
> @@ -1636,17 +1657,21 @@ void
virNetClientIncomingEvent(virNetSocketPtr sock,
> VIR_DEBUG("%s : VIR_EVENT_HANDLE_HANGUP or "
> "VIR_EVENT_HANDLE_ERROR encountered", __FUNCTION__);
> virNetSocketRemoveIOCallback(sock);
> - goto done;
> + goto eof;
> }
>
> if (events & VIR_EVENT_HANDLE_WRITABLE) {
> - if (virNetClientIOHandleOutput(client) < 0)
> + if (virNetClientIOHandleOutput(client) < 0) {
> virNetSocketRemoveIOCallback(sock);
> + goto eof;
> + }
> }
>
> if (events & VIR_EVENT_HANDLE_READABLE) {
> - if (virNetClientIOHandleInput(client) < 0)
> + if (virNetClientIOHandleInput(client) < 0) {
> virNetSocketRemoveIOCallback(sock);
> + goto eof;
> + }
> }
What about the case ?
if (client->haveTheBuck || client->wantClose) ?
sure it's induced locally instead of getting raised by an eof
If either of those conditions are true, the virNetClientIncomingEvent
method should not be invoked - we just have a check for those at the
top as a sanity check. In the haveTheBuck==true case, this callback
will be activated again once the buck is released, so we'll deal with
EOF callbacks correctly. In the wantClose==true case, we might miss
out invoking the EOF callback - I suspect this is only a problem if
the app code explicitly asked for a close itself, or if the keepalive
code triggers.
I'll check into this and if there are any fixes required, I'll do them
as a followup patch.
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|