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