[libvirt] PATCH: 0/4: Fix the event loop (again) no really, this time its fixed.
Back in March I attempted to fix the event loop handling of deleted file handles http://www.redhat.com/archives/libvir-list/2009-March/msg00246.html but have merely succeeded in screwing it up in a different fun exciting way. That patch fixed a case where there was a deleted file handle in the list at the time virEventRunOnce() starts. Which was nice. Not nice, though was that it then breaks the case where a file handle is deleted during the course of dispatching events afer poll(). Investigating this also identified that when we were marking a file handle as deleted, we were forgetting to run virEventInterrupt(), which meant that in some cases the main thread would not be woken up until the next event triggers. Not very critical, but at the same time, not good because it delays cleanup release of resources. This series of patches fixes the problems, and more importantly, adds a unit test which cover these nasty edge cases. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 0/4: Fix the event loop (again) no really, this time its fixed.
On Mon, 2009-05-11 at 12:11 +0100, Daniel P. Berrange wrote: Back in March I attempted to fix the event loop handling of deleted file handles http://www.redhat.com/archives/libvir-list/2009-March/msg00246.html but have merely succeeded in screwing it up in a different fun exciting way. That patch fixed a case where there was a deleted file handle in the list at the time virEventRunOnce() starts. Which was nice. Not nice, though was that it then breaks the case where a file handle is deleted during the course of dispatching events afer poll(). Investigating this also identified that when we were marking a file handle as deleted, we were forgetting to run virEventInterrupt(), which meant that in some cases the main thread would not be woken up until the next event triggers. Not very critical, but at the same time, not good because it delays cleanup release of resources. This series of patches fixes the problems, and more importantly, adds a unit test which cover these nasty edge cases. It's not obvious to me from your description, so for others, one of the problems these patches fix is where destroying one running guest can cause another to also be destroyed: https://bugzilla.redhat.com/499698 Cheers, Mark. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 0/4: Fix the event loop (again) no really, this time its fixed.
On Mon, May 11, 2009 at 12:47:38PM +0100, Mark McLoughlin wrote: On Mon, 2009-05-11 at 12:11 +0100, Daniel P. Berrange wrote: Back in March I attempted to fix the event loop handling of deleted file handles http://www.redhat.com/archives/libvir-list/2009-March/msg00246.html but have merely succeeded in screwing it up in a different fun exciting way. That patch fixed a case where there was a deleted file handle in the list at the time virEventRunOnce() starts. Which was nice. Not nice, though was that it then breaks the case where a file handle is deleted during the course of dispatching events afer poll(). Investigating this also identified that when we were marking a file handle as deleted, we were forgetting to run virEventInterrupt(), which meant that in some cases the main thread would not be woken up until the next event triggers. Not very critical, but at the same time, not good because it delays cleanup release of resources. This series of patches fixes the problems, and more importantly, adds a unit test which cover these nasty edge cases. It's not obvious to me from your description, so for others, one of the problems these patches fix is where destroying one running guest can cause another to also be destroyed: https://bugzilla.redhat.com/499698 NB That's just one symptom. The core problem is that you end up with an off-by-1 error when dispatching the callbacks. ie, instead of dispatching the nth callback, we dispatch the nth+1 callbck. There are lots of different things registering callbacks so effects are pretty unpredictable. Normally the callbacks for running guests don't align, but if you restart libvirtd while a set of guests are running, you end up with all the guest callbacks registered in series, so are quite likely to see this double destroy. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
