[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