[Top][All Lists]

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

Re: [Qemu-devel] Question on aio_poll

From: Alex Bligh
Subject: Re: [Qemu-devel] Question on aio_poll
Date: Wed, 24 Jul 2013 09:05:03 +0100


--On 24 July 2013 09:54:39 +0200 Stefan Hajnoczi <address@hidden> wrote:

I left this how it was in the end (I think), and got round it by
creating a bogus pipe for the test to listen to.

Doing that requires the changes in my patch series, otherwise you break
aio_poll() loops that are waiting for pending I/O requests.  They don't
want to wait for timers.

Sorry I meant leaving the main code as is, and creating the bogus
pipe solely in tests/test-aio.c in my new test that tests a timer
attached to AioContext - no changes elsewhere.

I hope we can eventually unify event loops and then the select function
should behave as you described.  For now though, we need to keep the
current behavior until my .io_flush() removal series or something
equivalent is merged, at least.

OK. That's pretty much the way I went with the PATCHv2 series.

I note you now have:
    if (ctx->pollfds->len == 1) {
        return progress;

Is the '1' there the event notifier? How do we know there is only
one of them?

There many be many EventNotifier instances.  That's not what matters.

Rather, it's about the aio_notify() EventNotifier.  Each AioContext has
its own EventNotifier which can be signalled with aio_notify().  The
purpose of this function is to kick an event loop that is blocking in
select()/poll().  This is necessary when another thread modifies
something that the AioContext needs to act upon, such as adding/removing
an fd.


Alex Bligh

reply via email to

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