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(a)redhat.com>
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 :|