Re: [Qemu-devel] [RFC v5 09/26] monitor: create monitor dedicate iothread

[Peter Xu]

On Wed, Dec 13, 2017 at 04:20:22PM +0000, Stefan Hajnoczi wrote:
> On Tue, Dec 05, 2017 at 01:51:43PM +0800, Peter Xu wrote:
> > @@ -208,6 +209,12 @@ struct Monitor {
> >      QTAILQ_ENTRY(Monitor) entry;
> >  };
> >  
> > +struct MonitorGlobal {
> > +    IOThread *mon_iothread;
> > +};
> > +
> > +static struct MonitorGlobal mon_global;
> 
> structs can be anonymous.  That avoids the QEMU coding style violation
> (structs must be typedefed):
> 
>   static struct {
>       IOThread *mon_iothread;
>   } mon_global;

Will fix this up.  Thanks.

> 
> In general global variables are usually top-level variables in QEMU.
> I'm not sure why wrapping globals in a struct is useful.

Because I see too many global variables for monitor code, and from
this patch I wanted to start moving them altogether into this global
struct.  I didn't really do that in current series because it's more
like a clean up, but if you see future patches, it at least grows with
new monitor global variables introduced with current series.

I can add a comment in the commit message, like: "Let's start to
create a struct to keep monitor global variables together".  Would
that help?

> 
> > @@ -4117,6 +4136,16 @@ void monitor_cleanup(void)
> >  {
> >      Monitor *mon, *next;
> >  
> > +    /*
> > +     * We need to explicitly stop the iothread (but not destroy it),
> > +     * cleanup the monitor resources, then destroy the iothread.  See
> > +     * again on the glib bug mentioned in 2b316774f6 for a reason.
> > +     *
> > +     * TODO: the bug is fixed in glib 2.28, so we can remove this hack
> > +     * as long as we won't support glib versions older than it.
> > +     */
> 
> I find this comment confusing.  There is no GSource .finalize() in
> monitor.c so why does monitor_cleanup() need to work around the bug?
> 
> I see that monitor_data_destroy() is not thread-safe so the IOThread
> must be stopped first.  That is unrelated to glib.

Yeah actually that's a suggestion by Dave and Dan in previous review
comments which makes sense to me:

  http://lists.gnu.org/archive/html/qemu-devel/2017-11/msg04344.html

I'm fine with either way: keep it as it is, or instead saying
"monitor_data_destroy() is not thread-safe" (which finally will still
root cause to that glib bug).  But how about we just keep it in case
it may be helpful some day?

Thanks,

> 
> > +    iothread_stop(mon_global.mon_iothread);
> > +
> >      qemu_mutex_lock(&monitor_lock);
> >      QTAILQ_FOREACH_SAFE(mon, &mon_list, entry, next) {
> >          QTAILQ_REMOVE(&mon_list, mon, entry);
> > @@ -4124,6 +4153,9 @@ void monitor_cleanup(void)
> >          g_free(mon);
> >      }
> >      qemu_mutex_unlock(&monitor_lock);
> > +
> > +    iothread_destroy(mon_global.mon_iothread);
> > +    mon_global.mon_iothread = NULL;
> >  }
> >  
> >  QemuOptsList qemu_mon_opts = {
> > -- 
> > 2.14.3
> > 

-- 
Peter Xu