On Tue, Jan 13, 2026 at 02:00:35PM +0100, Markus Armbruster wrote: > Daniel P. Berrangé <[email protected]> writes: > > > On Tue, Jan 13, 2026 at 10:27:04AM +0100, Markus Armbruster wrote: > >> Daniel P. Berrangé <[email protected]> writes: > >> > >> > This will be used to include the thread name in error reports > >> > in a later patch. It returns a const string stored in a thread > >> > local to avoid memory allocation when it is called repeatedly > >> > in a single thread. The thread name should be set at the very > >> > start of the thread execution, which is the case when using > >> > qemu_thread_create. > >> > > >> > Signed-off-by: Daniel P. Berrangé <[email protected]> > >> > --- > >> > include/qemu/thread.h | 1 + > >> > meson.build | 21 +++++++++++++++++ > >> > util/qemu-thread-posix.c | 33 ++++++++++++++++++++++++++- > >> > util/qemu-thread-win32.c | 49 ++++++++++++++++++++++++++++++++++++---- > >> > 4 files changed, 99 insertions(+), 5 deletions(-) > >> > >> Tempted to store the thread name in TLS and call it a day. > > > > Using the official APIs in this way ensures that the thread name is > > visible outside QEMU. For example when debugging in GDB, which IMHO > > is an important benefit. > > I didn't mean to suggest not to set the "official" thread name. > > This patch retrieves the "official" thread name back. Takes a bit of > system-specific code, including Meson magic. We could instead hold on > to our own copy, and just use that.
That would mean we don't get any names for threads which are spawned indirectly. There are quite a lot of libraries that QEMU can use, which can spawn threads behind QEMU's back, and these threads can still be running QEMU code through callbacks. spice, gstreamer, jack and librbd are some I know that spawn threads, but there are likely quite a few more. In the the jack case we hook into its thread creation to set a name ourselves, but we can't rely on that in general, and these libraries may well have set thread names we should use. I want to maximise the cases where we can retrieve a thread name. While the code is more verbose than I'd like, it exists now so I don't think its good to throw it away to put into a worse solution. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
