On Fri, May 22, 2015 at 12:42:34AM +0200, Jiri Denemark wrote: > Our usage of pthread conditions does not allow a single thread to wait > for several events from different sources. This is because the condition > is bound to the source of the event. We can invert the usage by giving > each thread its own condition and providing APIs for registering this > thread condition with several sources. Each of the sources can then > signal the thread condition. > > Thread queues also support several threads to be registered with a > single event source, which can either wakeup all waiting threads or just > the first one. > > Signed-off-by: Jiri Denemark <jdenemar@xxxxxxxxxx> I'm not really convinced this abstraction is neccessary / appropriate. I can see what you mean about the problems with migration having access to several different virCond's that it needs to wait on, but AFAICT, all the condition variables are ultimately associated with a single guest domain. So it seems the problem could have been solved much more simply by just having a single virCond in the qemuDomainObjPrivate struct. Moving to a centralized single condition var per thread feels like it is really breaking encapsulation of the APIs across the codebase. Regards, 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list