Re: [Qemu-devel] [PATCH 2/2] qemu-thread: let cur_mon be per-thread

[Peter Xu <peterx@redhat.com>]

On Wed, Apr 11, 2018 at 11:23:57AM +0200, Paolo Bonzini wrote:
> On 11/04/2018 05:49, Peter Xu wrote:
> > On Wed, Apr 11, 2018 at 09:45:32AM +0800, Stefan Hajnoczi wrote:
> >> On Tue, Apr 10, 2018 at 08:49:13PM +0800, Peter Xu wrote:
> >>> cur_mon was only used in main loop so we don't really need that to be
> >>> per-thread variable.  Now it's possible that we have more than one
> >>> thread to operate on it.  Let's start to let it be per-thread variable.
> >> Trying to understand the reason for this patch:
> >>
> >> Are there any users of per-thread cur_mon?
> > 
> > Currently no.  But if considering future OOB-capable commands, they
> > will modify cur_mon in monitor IOThread at least.
> 
> That's fine, but it shouldn't need the inheritance part.  The monitor
> IOThread can set cur_mon when it starts.

Yeah, the inheritance will only make sure cur_mon be initialized
always with correct value just like when we are without Out-Of-Band.
For example, it's still possible a thread is created within a QMP
handler.  If without current change, the cur_mon in the new thread
would be NULL.

AFAIU even if cur_mon==NULL we should mostly be fine (e.g.,
error_vprintf will handle that case well).  If any of you can help me
confirm this, then I agree that this patch is not really needed.

If so, maybe even we don't need to setup cur_mon at entry of monitor
iothread, since cur_mon is always used in the way like:

  old_mon = cur_mon;
  cur_mon = xxx;
  ... (do something)
  cur_mon = old_mon;

And it'll be fine old_mon==NULL here.  Then IMHO the only thing we
need to do is to mark cur_mon as per-thread and we're done.

Thanks,

-- 
Peter Xu