Hi On Fri, Aug 25, 2017 at 6:29 PM Dr. David Alan Gilbert <dgilb...@redhat.com> wrote:
> * Marc-André Lureau (marcandre.lur...@gmail.com) 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
