qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 2/9] block-copy: add missing coroutine_fn annotations


From: Paolo Bonzini
Subject: Re: [PATCH 2/9] block-copy: add missing coroutine_fn annotations
Date: Thu, 3 Nov 2022 19:36:49 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0

On 11/3/22 19:06, Kevin Wolf wrote:
I think it can make sense to have coroutine_fn as a documentation for
things that are only ever called in a coroutine even if they could
theoretically also work outside of coroutine context.

Otherwise, when we want to introduce a coroutine_fn call somewhere, it's
not only less obvious that it's even possible to do, but we'll have to
add potentially many additional coroutine_fn annotations in the whole
call chain in an otherwise unrelated patch.

This is true. On the other hand, coroutine_fn also means "this is allowed to suspend", which may have implications on the need for locking in the caller. So you need to judge case-by-case.

If there are good reasons to add the note, you could add an assertion that you are qemu_in_coroutine(), which notes that you are in a coroutine but you don't suspend. In this case however I don't think it's likely that there will be a coroutine_fn call added later.

I guess I tend to err on the side of "it's good that it's not obvious that you can call a coroutine_fn", but I also need to correct myself as qemu_coroutine_yield() is not the only leaf; there is also qemu_co_queue_next() and qemu_co_queue_restart_all(), which are coroutine_fn because they rely on the queuing behavior of aio_co_enter(). In this case I violated my own rule because it is always a bug to call these functions outside coroutine context.

Paolo




reply via email to

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