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