Re: [Qemu-devel] [RFC v2 2/8] monitor: allow monitor to create thread to poll

[Marc-André Lureau]

Hi

On Fri, Aug 25, 2017 at 6:29 PM Dr. David Alan Gilbert <address@hidden>
wrote:

> * Marc-André Lureau (address@hidden) wrote:
> > > In (2),  info cpus
> > > > shouldn't keep the BQL (my qapi-async series would probably help
> here)
> > >
> > > How does that work?
> > >
> > >
> > https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg03626.html
> >
> > With the series, a command can be broken up in receive/start &
> > finish/reply. This allows to reenter the loop, potentially freeing the
> BQL,
> > and process other events. This allowed me to fix a screendump glitch bug
> (
> > http://lists.gnu.org/archive/html/qemu-devel/2017-01/msg03650.html).
> This
> > also open the door to concurrent QMP commands (if the client turns on the
> > capability option).
>
> Interesting.
> I can see how that would work well for commands that know they're long
> lived and do that work to split themselves into
> receive/start/finish/reply.  However I'm worried that it means that
> it's fragile in that if something accesses guest memory when they din't
> realise they were doing, or code that forgot it's taking the lock, then
> we've got a command that can occasionally block.  That's going to be a
> lot of analysis and design on each command and if we were to do it
> widely then we'd certainly miss some cases.  Having the monitors in
> spearate threads means you only have to worry about the commands
> you want to be lock-free.
>

Well the concurrency problems are essentially similar in both cases, but I
would argue that avoiding parallelism is easier to deal with. My approach
is also very conservative, only commands that are "async-free" are broken
up, so you mostly have to worry about those regarding concurrency. But with
a seperate thread, you have additional concerns, since you may run while
the BQL is taken somewhere else.

-- 
Marc-André Lureau