On 02/11/2018 14:33, Peter Maydell wrote: > On 9 October 2018 at 12:16, Paolo Bonzini <pbonz...@redhat.com> wrote: >> On 08/10/2018 18:40, Kevin Wolf wrote: >>>> >>>> I'm pretty confident this analysis of the problem is correct: >>>> unfortunately I have no idea what the right way to fix it is... >>> Yes, I agree with your analysis. If __thread variables can be destructed >>> before pthread_key_create() destructors are called (and in particular if >>> the former are implemented in terms of the latter), this implies at >>> least two rules: >>> >>> 1. The Notfier itself can't be a TLS variable >>> >>> 2. The notifier callback can't access any TLS variables >>> >>> Of course, with these restrictions, qemu_thread_atexit_*() with its >>> existing API is as useless as it could be. >> >> Yup, we have to stop using pthread_key_create. Luckily, these days >> there is always qemu_thread_start that wraps the thread, so we can call >> qemu_thread_atexit_run from there, and change exit_key to a thread-local >> NotifierList. > > We would also need to catch exits via qemu_thread_exit(), right? > We probably also need to handle the main thread specially, via > atexit(). This seems to be pretty much what we already do in > util/qemu-thread-win32.c...
There's only one caller of qemu_thread_exit and it can be removed easily. However, an improvement on the idea is to use pthread_cleanup_push/pop in qemu_thread_start. This does handle qemu_thread_exit. Thanks, Paolo
