Re: [Qemu-devel] chardev's and fd's in monitors

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Paolo Bonzini (pbonzini@redhat.com) wrote:
> 
> 
> On 18/10/2016 16:01, Daniel P. Berrange wrote:
> >> > 
> >> > I already use error_report's in places in migration threads of various
> >> > types; I'm not sure if that's a problem.
> > Unless those places are protected by the big qemu lock, that sounds
> > not good. error_report calls into error_vprintf which checks the
> > 'cur_mon' global "Monitor" pointer. This variable is updated at
> > runtime - eg in qmp_human_monitor_command(), monitor_qmp_read(),
> > monitor_read(), etc. So if migration threads outside the BQL are
> > calling error_report() that could well cause problems. If you
> > are lucky messages will merely end up going to stderr instead of
> > the monitor, but in worst case I wouldn't be surprised if there
> > is a crash possibility in some race conditions.
> 
> Writes to chardevs *are* thread-safe (assuming qio_channel_create_watch
> is thread-safe; it seems to be).

Hmm that's useful (although it doesn't solve error_report because error_vprintf
is racy itself).

How deadlock safe is it?  In particular imagine I've got another
thread which is doing:
  take bql
     <many layers of stuff>
     write to a chardev
  release bql

  if that chardev is registered on the main thread, will that
deadlock?

> Only reads aren't, in the sense that they require an event loop so they
> use that event loop for serialization.

Hmm OK.

Dave

> 
> Paolo
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK