On Thu, Jul 19, 2012 at 09:58:58AM +0100, Daniel P. Berrange wrote:
> 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.
Okay, ACK !
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list