Re: [Qemu-devel] [PULL 6/7] monitor: move init global earlier

[Markus Armbruster]

Peter Xu <address@hidden> 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 <address@hidden>
>> > 
>> > 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.