On 21.07.2020 19:09, Daniel P. Berrangé wrote:
On Tue, Jul 14, 2020 at 12:32:58PM +0300, Nikolay Shirokovskiy
wrote:
> The change won't hurt much current callers performance I guess and now we can
> use the function when we need to be sure of synchronous thread exit as well.
I can't remember the exact scenario, but I'm reasonably sure i tried
this approach when adding the event thread support and hit scenario
where this would deadlock.
>
> Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy(a)virtuozzo.com>
> ---
> src/qemu/qemu_domain.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index 2d9d822..18651d0 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -1571,6 +1571,7 @@ qemuDomainObjStopWorker(virDomainObjPtr dom)
> qemuDomainObjPrivatePtr priv = dom->privateData;
>
> if (priv->eventThread) {
> + virEventThreadClose(priv->eventThread);
> g_object_unref(priv->eventThread);
IIRC, it was something like this unref does not always release the
last reference.
> priv->eventThread = NULL;
IOW, despite setting evnetThread to NULL, the thread may linger for
a short while longer in the background until any operations have
completed.
Yeah, we can not stop event loop thread synchronously when call
qemuDomainObjStopWorker from qemuProcessHandleMonitorEOF as
the latter is called from event loop.
Hmm, pthread_join will fail in this case:
EDEADLK
A deadlock was detected (e.g., two threads tried to join with each
other); or thread specifies the calling thread.
Anyway, make sense calling virEventThreadClose optional.
Nikolay