[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] monitor: Protect outbuf from concurrent access

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH] monitor: Protect outbuf from concurrent access
Date: Fri, 02 Sep 2011 10:20:51 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

On 09/02/2011 10:18 AM, Gerd Hoffmann wrote:

A patch like the attached (warning: untested) should do as quick&dirty
fix for stable. But IMO we really should fix spice instead.

I agree. I'm not sure I like the idea of still calling QEMU code without
holding the mutex (even the QObject code).

I though just creating the objects isn't an issue, but if you disagree
we can just move up the lock to the head of the function.

What I fear is that Spice will assume something is thread safe, but then someone will make a change that makes the subsystem non-reentrant.

I'd rather that we have very clear rules about what's thread safe and not thread safe. If you want to audit the QObject subsystem, declare it thread safe, and document it as such, that would be okay. But it needs to be systematic, not ad-hoc.


Anthony Liguori

Can you just use a bottom half to defer this work to the I/O thread?
Bottom half scheduling has to be signal safe which means it will also be
thread safe.

Not that straight forward as I would have to pass arguments to the
bottom half.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]