On 10/07/2010 09:52 AM, Daniel Veillard wrote:
On Wed, Oct 06, 2010 at 05:56:36PM -0400, Stefan Berger wrote:
V2:
remove the locks from qemudVMFilterRebuild& umlVMFilterRebuild
For now I want to put this out as an RFC patch. I have tested it by
'stretching' the critical section after the define/undefine
functions each lock the filter so I can (easily) concurrently
execute another VM operation (suspend,start). That code is in this
patch and if you want you can de-activate it. It seems to work ok
and operations are being blocked while the update is being done.
I still also want to verify the other assumption above that locking
filter and qemu_domain always has a preceding qemu_driver lock.
I looked at the patch and the only thing that need to be cleaned up
is the stretching blocki below, otherwise looks fine to me.
Yes, I'll remove that.
+if (true) {
+ fprintf(stderr,"sleep in %s\n", __FUNCTION__);
+ sleep(CRITICAL_SECTION_STRETCH);
+ fprintf(stderr,"continue in %s\n", __FUNCTION__);
+}
+
It would be good to have some ways to exercise all code paths
in the locking (okay error handling specific paths aside because
it's really hard), before applying.
It will take some time, but I'll try to write a TCK test that does
something like Soren was testing:
- concurrently create/destroy 2 vms
- concurrently modify their filters
- plus occasionally shoot a SIGHUP at libvirt ( if possible )
That would test some of the code paths.
Stefan
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list