On 12.02.2013 21:35, Eric Blake wrote: > 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. > > I've done some stress testing (repetitive suspend + resume of several domains at once - with compression of image enabled, iohelper, ...) and since it didn't stuck anywhere or broke in any other way I took your ACK sufficient and pushed. This is a bugfix of a race not enhancement after all. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list