[Qemu-devel] Qemu coroutine behaviour on blocking send(3)

[Qemu-devel] Qemu coroutine behaviour on blocking send(3)

[Iwan Budi Kusnanto]

Hi all,

I just found about coroutine in Qemu and it looks good for my use case.
I have a question about this.
I found this
"Coroutines are cooperatively scheduled threads of control. There is
no preemption timer that switches between coroutines periodically,
instead switching between coroutines is always explicit. Coroutines
run until termination or an explicit yield."
at http://blog.vmsplice.net/2014/01/coroutines-in-qemu-basics.html

How about the case where we do blocking send(3) on socket?

Regards,

-- 
Iwan Budi Kusnanto

Re: [Qemu-devel] Qemu coroutine behaviour on blocking send(3)

[Iwan Budi Kusnanto]

I meant, does the coroutine will do yield internally when it get
blocked on send(3)?

On Fri, Nov 28, 2014 at 1:50 PM, Iwan Budi Kusnanto <ibk@labhijau.net> wrote:
> Hi all,
>
> I just found about coroutine in Qemu and it looks good for my use case.
> I have a question about this.
> I found this
> "Coroutines are cooperatively scheduled threads of control. There is
> no preemption timer that switches between coroutines periodically,
> instead switching between coroutines is always explicit. Coroutines
> run until termination or an explicit yield."
> at http://blog.vmsplice.net/2014/01/coroutines-in-qemu-basics.html
>
> How about the case where we do blocking send(3) on socket?
>
> Regards,
>
> --
> Iwan Budi Kusnanto



-- 
Iwan Budi Kusnanto

Re: [Qemu-devel] Qemu coroutine behaviour on blocking send(3)

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

On Fri, Nov 28, 2014 at 01:55:00PM +0700, Iwan Budi Kusnanto wrote:
> I meant, does the coroutine will do yield internally when it get
> blocked on send(3)?

No.  In general, QEMU will use non-blocking file descriptors so the
blocking case does not apply.  (You can't use blocking file descriptors
in an event loop without a risk of blocking the entire event loop.)

There is qemu_co_send(), which attempts the non-blocking send(2) and
yields on EAGAIN.

block/sheepdog.c and nbd.c both use this function.  It's a little ugly
because the caller must add/remove the socket write fd handler function
so that the coroutine is re-entered when the fd becomes writable again.

Stefan

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] Qemu coroutine behaviour on blocking send(3)

[Iwan Budi Kusnanto]

On Fri, Nov 28, 2014 at 7:47 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> On Fri, Nov 28, 2014 at 01:55:00PM +0700, Iwan Budi Kusnanto wrote:
>> I meant, does the coroutine will do yield internally when it get
>> blocked on send(3)?
>
> No.  In general, QEMU will use non-blocking file descriptors so the
> blocking case does not apply.  (You can't use blocking file descriptors
> in an event loop without a risk of blocking the entire event loop.)
>
> There is qemu_co_send(), which attempts the non-blocking send(2) and
> yields on EAGAIN.
>
> block/sheepdog.c and nbd.c both use this function.  It's a little ugly
> because the caller must add/remove the socket write fd handler function
> so that the coroutine is re-entered when the fd becomes writable again.
>
> Stefan

Thanks Stefan, it really helps.



-- 
Iwan Budi Kusnanto

Re: [Qemu-devel] Qemu coroutine behaviour on blocking send(3)

[Paolo Bonzini]

On 28/11/2014 14:46, Iwan Budi Kusnanto wrote:
> On Fri, Nov 28, 2014 at 7:47 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>> On Fri, Nov 28, 2014 at 01:55:00PM +0700, Iwan Budi Kusnanto wrote:
>>> I meant, does the coroutine will do yield internally when it get
>>> blocked on send(3)?
>>
>> No.  In general, QEMU will use non-blocking file descriptors so the
>> blocking case does not apply.  (You can't use blocking file descriptors
>> in an event loop without a risk of blocking the entire event loop.)
>>
>> There is qemu_co_send(), which attempts the non-blocking send(2) and
>> yields on EAGAIN.
>>
>> block/sheepdog.c and nbd.c both use this function.  It's a little ugly
>> because the caller must add/remove the socket write fd handler function
>> so that the coroutine is re-entered when the fd becomes writable again.
> 
> Thanks Stefan, it really helps.

I'll add that outgoing migration _does_ use blocking file descriptors.
But it runs in a separate thread and does not use coroutines.

Incoming migration, instead, uses coroutines, because it is not as
performance-intensive as outgoing migration and it's a bit easier to not
worry about thread-safety.

Paolo