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

[Anthony Liguori <anthony@codemonkey.ws>]

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.  I think it's much 
better to just use GIdle sources though.

>> This can actually be made to work with sync I/O emulation too by
>> having another GMainLoop in the sync I/O loop although I thought I
>> recalled a patch series to remove that stuff.
>
> ... which stuff? :)

The sync I/O emulation.  Since sync I/O is done in block drivers, they can just 
use coroutine I/O instead of sync I/O.

> Another GMainLoop in the sync I/O loop is problematic for
> two reasons: 1) the sync I/O loop does not relinquish the I/O thread mutex,
> which makes it very different from the outer loop; 2) a nested GMainLoop keeps
> polling all the file descriptors in the outer loop, which requires you to cope
> with reentrancy in those monitor commands that flush AIO.

Re: (2), you can use a separate aio GMainContext.  The trick is that you need to 
keep a global current main context that switches when you enter the AIO main loop.

It's doable, but since I think we're on the verge of eliminating sync I/O 
emulation, that's probably a better path to pursue.

Regards,

Anthony Liguori

>
> Paolo
>