On Thu, Sep 20, 2018 at 06:14:11PM +0200, Markus Armbruster wrote: > Wolfgang Bumiller <w.bumil...@proxmox.com> writes: > > > On Thu, Sep 20, 2018 at 04:10:00PM +0800, Peter Xu wrote: > >> On Thu, Sep 20, 2018 at 10:02:22AM +0200, Wolfgang Bumiller wrote: > >> > >> > Either way, spawning the iothread on demand can still make sense, as > >> > does updating the check in resume()/suspend(). > >> > >> Yep. > > > > Running into an issue with that approach though: the qmp_dispatcher_bh > > is being used even without mon_iothread from out of > > handle_qmp_command(). I'm not sure how to deal with this. I suppose it > > depends on whether the qmp_* functions in this case would be coming in > > from the main thread? > > Can you describe the issue in a bit more detail?
I was just getting code blind. monitor_iothread_init() creates the thread as well as qmp_dispatcher_bh and qmp_respond_bh. For the latter it passes the thread's AIO context. I thought it did that for both, which would have been an issue when not creating the thread, but we only need qmp_dispatcher_bh when no thread is used. It's used in handle_qmp_command(). Sending patches to review in a bit.
