Peter Xu <pet...@redhat.com> writes: > On Wed, Sep 05, 2018 at 05:05:10PM +0200, Wolfgang Bumiller wrote: >> On Mon, Jun 18, 2018 at 04:08:53PM +0200, Markus Armbruster wrote: >> > From: Peter Xu <pet...@redhat.com> >> > >> > Before this patch, monitor fd helpers might be called even earlier than >> > monitor_init_globals(). This can be problematic. >> > >> > After previous work, now monitor_init_globals() does not depend on >> > accelerator initialization any more. Call it earlier (before CLI >> > parsing; that's where the monitor APIs might be called) to make sure it >> > is called before any of the monitor APIs. >> >> It looks like this patch moves the creation of the 'IO mon_iothread' to >> before the call to os_daemonize(). >> With qemu 3.0 I'm experiencing crashes when shutting down daemonized >> qemu instances, at pthread_join() on the 'IO mon_iothread' thread. >> >> monitor_init_globals() calls monitor_iothread_init(), which in turn uses >> iothread_create() to create a joinable thread. Then os_daemonize() is >> called after which the thread is no longer "ours". >> Debug-writing the thread IDs at pthread_create() and pthread_join() >> together with the 'detachable' flag revealed that the mon_iothread ID is >> already being reused, in my trace for a detached thread, and the join >> then ends with a coredump and ugly log output.
I'm slow today. Can you explain this again, with a bit more detail? > Indeed. So we have these ordering constraints: > > init mon locks [1] > cli parsing > daemonize > create mon iothread [2] > > I can't figure out a way unless we split the global init routine for > the monitors, possibly (and simply) by postpone creation of the > iothread. Thoughts? Instead of creating @mon_iothread eagerly in monitor_init_globals(), we could perhaps create it lazily when we create the first monitor with mon->use_io_thread.
