Re: [Qemu-devel] [PATCH] event_notifier: move to top-level directory

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2011-09-28 08:27, Paolo Bonzini wrote:
> On 09/27/2011 11:23 PM, Anthony Liguori wrote:
>> On 09/27/2011 11:39 AM, Paolo Bonzini wrote:
>>> On 09/27/2011 06:05 PM, Anthony Liguori wrote:
>>>> Actually, for posix-aio, we can just switch to using g_idle_add().
>>>> g_idle_add() uses g_source_attach which is thread safe. g_idle_add()
>>>> gives you a thread safe mechanism to defer a piece of work to the
>>>> main loop which is really what we want here.
>>>
>>> For that, a bottom half would also do (apart that I am not sure it is
>>> async-safe with TCG). In fact, that would make sense since all of
>>> posix_aio_process_queue could become a bottom half.
>>
>> Bottom halves are signal safe, not thread safe.
>>
>> To make bottom halves thread safe, you would (in the very least) have to
>> add some barriers when reading/writing the scheduling flag.
> 
> You can probably assume that qemu_notify_event (and dually the read in 
> the main loop) are resp. write/read memory barriers.  Or even full.
> 
> If we switch entirely to GSources, it would be nice to use them.  But 
> since we aren't, and our main loop functionality is quite different from 
> glib's (it doesn't rely on abstractions for file descriptors, for 
> example), it is just a painful incomplete transition to use glib's idle 
> sources to do the exact same thing that is done by bottom halves (which 
> are already in our toolbox).

BTW, I just wondered if there is anything conceptually preventing to
skip this ping pong between AIO thread and main loop and just run the
completion over the former context (under global lock protection of course).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux