All of lore.kernel.org
 help / color / mirror / Atom feed
From: Charlie Shepherd <charlie@ctshepherd.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: kwolf@redhat.com, pbonzini@redhat.com, gabriel@kerneis.info,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/5] Add an explanation of when a function should be marked coroutine_fn
Date: Thu, 08 Aug 2013 02:20:29 +0100	[thread overview]
Message-ID: <5202F25D.8010601@ctshepherd.com> (raw)
In-Reply-To: <20130806083912.GC32024@stefanha-thinkpad.redhat.com>

On 06/08/2013 09:39, Stefan Hajnoczi wrote:
> On Mon, Aug 05, 2013 at 08:44:03PM +0200, Charlie Shepherd wrote:
>> From: Charlie Shepherd <cs648@cam.ac.uk>
>>
>> Coroutine functions that can yield directly or indirectly should be annotated
>> with a coroutine_fn annotation. Add an explanation to that effect in
>> include/block/coroutine.h.
>> ---
>>   include/block/coroutine.h | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/include/block/coroutine.h b/include/block/coroutine.h
>> index 377805a..3b94b6d 100644
>> --- a/include/block/coroutine.h
>> +++ b/include/block/coroutine.h
>> @@ -37,6 +37,9 @@
>>    * static checker support for catching such errors.  This annotation might make
>>    * it possible and in the meantime it serves as documentation.
>>    *
>> + * A function must be marked with coroutine_fn if it can yield execution, either
>> + * directly or indirectly.
>> + *
> This is correct except for the case of dynamic functions that do:
>
>    if (qemu_in_coroutine()) {
>    } else {
>        Coroutine *co = qemu_coroutine_new(...);
>        ...
>    }
>
> Here the function is coroutine_fn only if the caller is in coroutine
> context.
>
> I think your comment update should include a note about this.  When
> you've split all dynamic functions into coroutine/non-coroutine versions
> then the note can be removed.

Hmm ok, I can add a note to that effect.


Charlie

  reply	other threads:[~2013-08-08  1:20 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-05 18:44 [Qemu-devel] RFC: [PATCH 0/5] Explicitly annotating coroutine_fn functions Charlie Shepherd
2013-08-05 18:44 ` [Qemu-devel] [PATCH 1/5] Add an explanation of when a function should be marked coroutine_fn Charlie Shepherd
2013-08-06  8:39   ` Stefan Hajnoczi
2013-08-08  1:20     ` Charlie Shepherd [this message]
2013-08-05 18:44 ` [Qemu-devel] [PATCH 2/5] qemu_coroutine_self should not be marked coroutine_fn as it cannot yield Charlie Shepherd
2013-08-07 19:18   ` Stefan Hajnoczi
2013-08-07 22:13     ` Gabriel Kerneis
2013-08-08  1:29       ` Charlie Shepherd
2013-08-08  6:16         ` Gabriel Kerneis
2013-08-08  9:10           ` Charlie Shepherd
2013-08-08  9:12             ` Gabriel Kerneis
2013-08-08  1:25     ` Charlie Shepherd
2013-08-05 18:44 ` [Qemu-devel] [PATCH 3/5] Convert BlockDriver to explicit coroutine annotations Charlie Shepherd
2013-08-05 19:23   ` Gabriel Kerneis
2013-08-05 19:33     ` Charlie Shepherd
2013-08-05 20:05       ` Gabriel Kerneis
2013-08-06  9:04         ` Kevin Wolf
2013-08-07 19:30       ` Stefan Hajnoczi
2013-08-08  1:31         ` Charlie Shepherd
2013-08-08  6:27         ` Gabriel Kerneis
2013-08-06  9:24   ` Kevin Wolf
2013-08-08  1:14     ` Charlie Shepherd
2013-08-05 18:44 ` [Qemu-devel] [PATCH 4/5] Convert block functions to coroutine versions Charlie Shepherd
2013-08-05 20:01   ` Gabriel Kerneis
2013-08-06  9:36   ` Kevin Wolf
2013-08-08  1:17     ` Charlie Shepherd
2013-08-05 18:44 ` [Qemu-devel] [PATCH 5/5] Convert block layer callers' annotations Charlie Shepherd
2013-08-05 20:15   ` Gabriel Kerneis
2013-08-08  1:19     ` Charlie Shepherd
2013-08-05 19:25 ` [Qemu-devel] RFC: [PATCH 0/5] Explicitly annotating coroutine_fn functions Charlie Shepherd
2013-08-06  7:06 ` Gabriel Kerneis
2013-08-06  9:37 ` Kevin Wolf
2013-08-08  1:22   ` Charlie Shepherd
2013-08-08  7:15     ` Kevin Wolf
2013-08-08  9:36       ` Charlie Shepherd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5202F25D.8010601@ctshepherd.com \
    --to=charlie@ctshepherd.com \
    --cc=gabriel@kerneis.info \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.