OK - it looks like my EventImpl was passing along the wrong bits.
I'll look into the "token" scheme suggested in an earlier email, and get this ready for re-submission.
Would you prefer a new patch series, as before - or another patch that modifies the prior series?
Daniel P. Berrange wrote on 10/20/2008 10:59 AM:
> On Mon, Oct 20, 2008 at 10:48:38AM -0400, Ben Guthro wrote:
>>> Just discovered one tiny problem here - need to check 'event' to see
>>> if the POLLHUP or POLLERR flags are set, and unregister the callback.
>>> Otherwise if you kill the server, the client will just spin on POLLHUP
>>> or ERR forever. Something like this ought todo the trick
>>>
>>> if (event & (POLLERR | POLLHUP)) {
>>> virEventRemoveHandle(fd);
>>> return;
>>> }
>>>
>> I've been looking over the rest of your changes.
>> Generally, I agree all these suggestions are good ones...except for the code above
>>
>> With this code in, I run the following test
>> 1. start libvirtd
>> 2. begin to monitor events with event-test
>> 3. virsh create foo.xml
>>
>> At this point, the event-test app encounters a HUP, or ERR, and stops
>> monitoring for events - it will only ever get the "Started" event
>
> That's a little odd - I'm not sure why 'event-test' would be getting
> a HUP/ERR when 'virsh' starts a domain.
>
> 'event-test' should only get a HUP/ERR if it looses its socket connection
> to the libvirtd server. Once you've lost the connection like this, the
> entire virConnectPtr is non-operative, and the client app needs to
> create a new virConnectPtr to re-connect. So removing the FD from the
> event loop shouldn't result in us loosing any events - we're already
> doomed there.to
>
>> I handle this in the event-test poll loop via
>>
>> if ( pfd.revents & POLLHUP ) {
>> DEBUG0("Reset by peer");
>> return -1;
>> }
>
> The integration into the event loop though is only something the app
> will have general control off - eg, in the example libvirt-glib code
> I posted its totally opaque to the app.
>
>> Is it not a reasonable restriction to require the client app to handle a Hangup?
>
> Once the socket is dead, all subsequent libvirt call made on that
> virConnectPtr object will throw errors, which the app should see.
> Though if they're only ever waiting for events, and not making any
> other calls, they'd not see it. Perhaps we could do with an explicit
> callback for connection disconnect.
>
>
> Daniel
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list