> On September 25, 2018 at 12:31 PM Peter Xu <pet...@redhat.com> wrote:
>
>
> On Tue, Sep 25, 2018 at 10:15:07AM +0200, Wolfgang Bumiller wrote:
> > Commit d32749deb615 moved the call to monitor_init_globals()
> > to before os_daemonize(), making it an unsuitable place to
> > spawn the monitor iothread as it won't be inherited over the
> > fork() in os_daemonize().
> >
> > We now spawn the thread the first time we instantiate a
> > monitor which actually has use_io_thread == true.
> > Instantiation of monitors happens only after os_daemonize().
> > We still need to create the qmp_dispatcher_bh when not using
> > iothreads, so this now still happens in
> > monitor_init_globals().
> >
> > Signed-off-by: Wolfgang Bumiller <w.bumil...@proxmox.com>
> > Fixes: d32749deb615 ("monitor: move init global earlier")
>
> Reviewed-by: Peter Xu <pet...@redhat.com>
> Tested-by: Peter Xu <pet...@redhat.com>
>
> Though note that after this patch monitor_data_init() is not thread
> safe any more (while it was), so we may need to be careful...
Is there a way to create monitors concurrently? If so, we could
add a mutex initialized in monitor_globals_init().
Another way would be to only defer to after os_daemonize() but still
stick to spawning the thread unconditionally. (Iow. call
monitor_iothread_init() after os_daemonize() from vl.c.)
