virCommand: Don't misuse the eventloop for async IO
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.
Showing
想要评论请 注册 或 登录