Re: [Qemu-block] [PATCH 1/3] io: Yield rather than wait when already in coroutine

[Eric Blake]

On 09/06/2017 03:50 AM, Daniel P. Berrange wrote:
> On Tue, Sep 05, 2017 at 02:11:12PM -0500, Eric Blake wrote:
>> The new qio_channel_{read,write}{,v}_all functions are documented
>> as yielding until data is available.  When used on a blocking
>> channel, this yield is done via qio_channel_wait() which spawns
>> a new coroutine under the hood (so it is the new entry point that
>> yields as needed); but if we are already in a coroutine (at which
> 
> qio_channel_wait doesn't spawn any coroutine - it simply rnus a
> nested event loop to wait for the channel...
> 
>> point QIO_CHANNEL_ERR_BLOCK is only possible if we are a
>> non-blocking channel), we want to yield the current coroutine
>> instead of spawning a new one.
> 
> ...none the less, I think this is ok.

Okay, tweaking the commit message:

    The new qio_channel_{read,write}{,v}_all functions are documented
    as yielding until data is available.  When used on a blocking
    channel, this yield is done via qio_channel_wait() which spawns
    a nested event loop under the hood (so it is that secondary loop
    which yields as needed); but if we are already in a coroutine (at
    which point QIO_CHANNEL_ERR_BLOCK is only possible if we are a
    non-blocking channel), we want to yield the current coroutine
    instead of spawning a nested event loop.

> 
> Acked-by: Daniel P. Berrange <address@hidden>
> 
> Regards,
> Daniel
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature