diff mbox

[RFC,v2,01/15] Add an explanation of when a function should be marked coroutine_fn

Message ID 1376070245-22557-1-git-send-email-charlie@ctshepherd.com
State New
Headers show

Commit Message

Charlie Shepherd Aug. 9, 2013, 5:43 p.m. UTC
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.

Signed-off-by: Charlie Shepherd <charlie@ctshepherd.com>
---
 include/block/coroutine.h | 8 ++++++++
 1 file changed, 8 insertions(+)

Comments

Stefan Hajnoczi Aug. 14, 2013, 2:14 p.m. UTC | #1
On Fri, Aug 09, 2013 at 07:43:51PM +0200, Charlie Shepherd wrote:
> 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.
> 
> Signed-off-by: Charlie Shepherd <charlie@ctshepherd.com>
> ---
>  include/block/coroutine.h | 8 ++++++++
>  1 file changed, 8 insertions(+)

A "Patch 00/NN" email that serves as a cover letter to explain the
background and motivation for a patch series usually helps reviews
understand the purpose of your patches.  git-format-patch --cover-letter
does this and git-publish automatically adds a cover letter when there
is more than one patch.

No need to resend, but please write a cover letter in the future.  It
will encourage reviews.

Stefan
Stefan Hajnoczi Aug. 29, 2013, 3:34 p.m. UTC | #2
I have left some comments.  At this point I think a v2 would be good so
that any ripple-effects on later patches can play out.

Stefan
diff mbox

Patch

diff --git a/include/block/coroutine.h b/include/block/coroutine.h
index 1f2db3e..1aae6e9 100644
--- a/include/block/coroutine.h
+++ b/include/block/coroutine.h
@@ -37,6 +37,14 @@ 
  * 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.
+ *
+ * Some functions dynamically determine whether to yield or not based on
+ * whether they are executing in a coroutine context or not. These functions
+ * do not need to be annotated coroutine_fn. Note that this practice is
+ * deprecated and is being phased out, new code should not do this.
+ *
  * For example:
  *
  *   static void coroutine_fn foo(void) {