Re: [PATCH] virCommand: Don't misuse the eventloop for async IO

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

 



On 02/08/2013 07:28 AM, Michal Privoznik wrote:
> Currently, if a command wants to do asynchronous IO, a callback
> is registered in the libvirtd eventloop to handle writes and
> reads. However, there's a race in virCommandWait. The eventloop
> may already be executing the callback, while virCommandWait is
> mangling internal state of virCommand. To deal with it, we need
> to either introduce locking or spawn a separate thread where we
> poll() on stdio from child. The former, however, requires to
> unlock all mutexes held, as the event loop may execute other
> callbacks which tries to lock one of the mutexes, deadlock and
> thus never wake us up. So it's safer to spawn a separate thread.
> ---
> 
> This is an alternative to:
> 
> https://www.redhat.com/archives/libvir-list/2013-February/msg00352.html

I definitely like this version better - callers are not impacted.  You
may still want to wait for danpb's review, but you have my:

ACK.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

--
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]