Re: [PATCH v2 10/13] qemu: avoid deadlock in qemuDomainObjStopWorker

On 10.08.2020 20:40, Daniel Henrique Barboza wrote: > > > On 7/23/20 7:14 AM, Nikolay Shirokovskiy wrote: >> We are dropping the only reference here so that the event loop thread >> is going to be exited synchronously. In order to avoid deadlocks we >> need to unlock the VM so that any handler being called can finish >> execution and thus even loop thread be finished too.

> > > Given that this code only makes sense when called from qemuDomainObjStopWorkerIter(), > I'd suggest removing the lock/unlock of this function (turning it into just a call > to qemuDomainObjStopWorker()) and move them inside the body of qemuDomainObjStopWorker(), > locking and unlocking the mutex inside the scope of the same function. > Hi, Daniel. Actually all callers of qemuProcessStop hold the lock. Moreover they even hold job condition. And calling qemuProcessStop without lock/job condition would be a mistake AFIU (qemuConnectDomainXMLToNative is the only exception I see that holds the lock but not the job condition. But this function creates new vm object that is not shared with other threads) I understand you concern but there are precedents. Take a look for example virDomainObjListRemove. The lock requirements are documented for virDomainObjListRemove and I can do it for qemuDomainObjStopWorker too but it looks a bit over documenting to me.

Nikolay