On Tue, Sep 25, 2018 at 01:09:57PM +0200, Wolfgang Bumiller wrote:
>
> > 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().
qmp_human_monitor_command() creates monitors dynamically, though not
concurrently since currently it's only possible to happen on the main
thread (and it's always setting use_io_thread to false now). So we
should be safe now.
>
> 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.)
Yeah I think that should work too (and seems good). I'll see how
Markus think.
Regards,
--
Peter Xu
