qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH v2 2/4] migration/multifd: Join the TLS thread


From: Peter Xu
Subject: Re: [RFC PATCH v2 2/4] migration/multifd: Join the TLS thread
Date: Mon, 13 Nov 2023 12:33:44 -0500

On Fri, Nov 10, 2023 at 05:02:39PM -0300, Fabiano Rosas wrote:
> @@ -826,7 +832,9 @@ static bool multifd_tls_channel_connect(MultiFDSendParams 
> *p,
>      trace_multifd_tls_outgoing_handshake_start(ioc, tioc, hostname);
>      qio_channel_set_name(QIO_CHANNEL(tioc), "multifd-tls-outgoing");
>      p->c = QIO_CHANNEL(tioc);
> -    qemu_thread_create(&p->thread, "multifd-tls-handshake-worker",
> +
> +    p->tls_thread = g_new0(QemuThread, 1);
> +    qemu_thread_create(p->tls_thread, "multifd-tls-handshake-worker",
>                         multifd_tls_handshake_thread, p,
>                         QEMU_THREAD_JOINABLE);

I understand your way of doing this, but personally I prefer bool and make
QemuThread not a pointer but still statically allocated.

Same comment to the next patch.

IMHO we can even add support for QemuThread in general to remember the bool
itself:

        struct QemuThread {
                pthread_t thread;
                bool thread_created;
        };

Changing qemu_thread_create() to set the bool, and join() to skip the real
join if it's not even created; clearing the bool otherwise after join()ed.
I _think_ it'll work transparently to existing callers, but start to allow
join() to be bypassed if thread not even created.

Thanks,

-- 
Peter Xu




reply via email to

[Prev in Thread] Current Thread [Next in Thread]