* Paolo Bonzini (pbonz...@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 / dgilb...@redhat.com / Manchester, UK
