On 8/11/20 3:39 AM, Nikolay Shirokovskiy wrote:
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.
Got it. Thanks for explaining.
Nikolay
