Re: [PATCH 01/10] util: Introduce thread queues

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]