On 20/11/2017 23:35, Jeff Cody wrote:
>> Is this a different "state" (in Stefan's parlance) than scheduled? In
>> practice both means that someone may call qemu_(aio_)coroutine_enter
>> concurrently, so you'd better not do it yourself.
>>
> It is slightly different; it is from sleeping with a timer via
> co_aio_sleep_ns and waking via co_sleep_cb. Whereas the 'co->scheduled' is
> specifically from being scheduled for a specific AioContext, via
> aio_co_schedule().
Right; however, that would only make a difference if we allowed
canceling a co_aio_sleep_ns. Since we don't want that, they have the
same transitions.
> In practice, 'co->schedule' and 'co->sleeping' certainly rhyme, at the very
> least.
>
> But having them separate will put the abort closer to where the problem lies,
> so it should make debugging a bit easier if we hit it.
What do you mean by closer? It would print a slightly more informative
message, but the message is in qemu_aio_coroutine_for both cases.
In fact, unifying co->scheduled and co->sleeping means that you can
easily abort when co_aio_sleep_ns is called on a scheduled coroutine, like
/* This is valid. */
aio_co_schedule(qemu_get_current_aio_context(),
qemu_coroutine_self());
/* But only if there was a qemu_coroutine_yield here. */
co_aio_sleep_ns(qemu_get_current_aio_context(), 1000);
Thanks,
Paolo
