Re: [Qemu-devel] [PATCH rebased 2/2] monitor: delay monitor iothread creation

[Peter Xu]

On Tue, Sep 25, 2018 at 01:09:57PM +0200, Wolfgang Bumiller wrote:
> 
> > On September 25, 2018 at 12:31 PM Peter Xu <address@hidden> 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 <address@hidden>
> > > Fixes: d32749deb615 ("monitor: move init global earlier")
> > 
> > Reviewed-by: Peter Xu <address@hidden>
> > Tested-by: Peter Xu <address@hidden>
> > 
> > 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