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