|
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:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 |
On 09/02/2011 10:18 AM, Gerd Hoffmann wrote:
Hi,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.
Regards, 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. cheers, Gerd
[Prev in Thread] | Current Thread | [Next in Thread] |