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