how to use coroutine in c language

zerop · 07-27-2014, 11:18 PM

http://www.chiark.greenend.org.uk/~s...oroutines.html

compile the code in above link directly

main.c:6:0: warning: "crReturn" redefined [enabled by default]
main.c:4:0: note: this is the location of the previous definition
main.c: In function ‘function’:
main.c:12:22: error: macro "crReturn" passed 2 arguments, but takes just 1
main.c:12:9: error: ‘crReturn’ undeclared (first use in this function)
main.c:12:9: note: each undeclared identifier is reported only once for each function it appears in
main.c: In function ‘main’:
main.c:19:6: error: ‘for’ loop initial declarations are only allowed in C99 mode
main.c:19:6: note: use option -std=c99 or -std=gnu99 to compile your code
main.c:20:19: error: expected expression before ‘do’

Code:

#include <stdio.h>

#define crBegin static int state=0; switch(state) { case 0:
#define crReturn(i,x) do { state=i; return x; case i:; } while (0)
#define crFinish }
#define crReturn(x) do { state=__LINE__; return x; \
                         case __LINE__:; } while (0)
int function(void) {
    static int i;
    crBegin;
    for (i = 0; i < 10; i++)
        crReturn(1, i);
    crFinish;
}

int main(void)
{
    crBegin;
        for(int c= 0; c<3; ++c)
           printf("%d", crReturn(c));
        crReturn(EOF);
        crFinish;
    return 0;
}

rtmistler · 07-28-2014, 06:56 AM

Also from that link you found:

Code:

Of course, this trick violates every coding standard in the book. Try doing this in
your company's code and you will probably be subject to a stern telling off if not
disciplinary action! You have embedded unmatched braces in macros, used case within
sub-blocks, and as for the crReturn macro with its terrifyingly disruptive contents.
. . It's a wonder you haven't been fired on the spot for such irresponsible coding
practice. You should be ashamed of yourself.

Yeah, the writer their self acknowledges that pretty much EVERYONE will lambaste them for writing or using that code.

I didn't take the time to read it all, I fast glanced.

It was written in 2000.

My statements on this are: K.I.S.S. "Keep It Simple, Stupid!"

There is NO, strike that "ZERO" point coding that way. I recommend you don't do that.

zerop · 07-28-2014, 10:16 PM

what is zero point coding

why not do this in device module?

this is the fastest reading file without blocking

rtmistler · 07-29-2014, 08:04 AM

You can write the original code and don't need to use all the preprocessor tricks that's merely so the code can look in the author's opinion more read-able. I do not agree.

When I say Zero point I mean there is "no value" in taking the original code and modifying it the way they have done.

johnsfine · 07-29-2014, 09:33 AM

What are you trying to accomplish?

If you have few and simple situations that conceptually call for co-routine structure, it is simpler to just explicitly manage the state yourself. It would be easier and more maintainable if the language had direct co-routine support, but it doesn't. So don't try to fake it.

If you have many and medium complexity situations that conceptually call for co-routine, AND have serious performance constraints, AND cannot include a little ASM code, then a macro kludge such as in that article could be correct. But obviously you would need to understand the usage, which your post demonstrates you do not.

But that combination of conditions (needed to make such a kludge appropriate) is unlikely.

Long ago, I hit many situations with multiple complex requirements for co-routines and strict performance requirements. My answer was ASM code to switch stacks, so that real co-routines could be used in C or C++. That avoids all the kludges of those macros and covers more complicated situations more efficiently and totally destroys portability.

There is a very narrow range of complexity for which managing the state variables explicitly is too messy but that macro kludge is workable. In more complex cases, the macro kludge doesn't work. In less complex cases the macro kludge is no more readable/maintainable than explicit state variables.

In modern programming, anyone with a non trivial requirement for co-routines uses multiple threads instead. Multi threads is less efficient than a kludge, which in turn is less efficient than real co-routines. Multi threads takes a certain learning curve (which is a good idea anyway) and a certain coding overhead to getting started. But despite those disadvantages, multi-threading is the popular and well supported answer for problems that conceptually call for co-routines.