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

[Michal Privoznik]

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