Daniel P. Berrangé <berra...@redhat.com> writes: > On Thu, Sep 11, 2025 at 03:21:04PM +0200, Christian Schoenebeck wrote: >> On Wednesday, September 10, 2025 8:03:42 PM CEST Daniel P. Berrangé wrote: >> > This has greater portability than directly call pthread_setname_np, >> > which is only 1 out of 3 possible functions for pthreads that can >> > set the name. >> > >> > The new API requires a trampoline function, since it can only set >> > the name of the current thread. >> > >> > Signed-off-by: Daniel P. Berrangé <berra...@redhat.com>
[...] >> Well, it does what you said, so: >> >> Reviewed-by: Christian Schoenebeck <qemu_...@crudebyte.com> >> >> I just wonder whether this thread naming code couldn't be much more >> simplified >> now by dropping jack_set_thread_creator() entirely, which is very seldomly >> used at all and had another user case [1]: >> >> "This function can be used in very very specialized cases where it is >> necessary that client threads created by JACK are created by something other >> than pthread_create(). After it is used, any threads that JACK needs for the >> client will will be created by calling the function passed to this function. >> >> No normal application/client should consider calling this. The specific case >> for which it was created involves running win32/x86 plugins under Wine on >> Linux, where it is necessary that all threads that might call win32 functions >> are known to Wine." >> >> [1] >> https://jackaudio.org/api/group__ClientThreads.html#ga157ab0ade60e266ffd26ddffdb5545af >> >> However there doesn't seem to be a thread creation callback in the JACK API, >> so the jack_set_thread_creator() bypass is still the best we can get, right? > > From QEMU's POV the only value we get from using the thread callback > is that we can set the thread name so the jack thrread can be easily > identified when debugging. I don't think there's another easy way > to get that set, as we can't portability set thread names from outside > the thread. As far as I can tell, this is due to Mac OS X. Personally, I wouldn't bother complicating things for that. But whoever wrote the code in qemu-thread-posix.c did, so ...
