Lightweight concurrency library for C, featuring symmetric coroutines

Re:Lightweight concurrency library for C, featuring symmetri... by halayli on Friday October 18, 2013 @01:21PM (#6572549)

I think lthread (http://github.com/halayli/lthread) is the only coroutine lib that allows you to block inside a coroutine and do heavy computation without affecting other coroutines.

Example:

  void my_function(void* arg)
  {
      char buf[1024];

      int ret = lthread_recv_exact(fd, buf, 1024, 0, timeout);

      lthread_compute_begin();
      /* block as long as you wish, run heavy computation on buf, access your stack variables etc.. */

      lthread_compute_end();
  }

Disclaimer: lthread author.

[ Parent | on HN ]

Re:Lightweight concurrency library for C, featuring symmetri... by regi on Friday October 18, 2013 @04:59PM (#6573974)

You show me yours, I show you mine ;) https://github.com/reginaldl/librinoo

Just to comment on your post, as using blocking calls in coroutine might be a nice feature I think it defeats the whole concept of coroutine. I might be missing the point but this kind of library is absolutely great for asynchronous network calls and in this specific case the library provides a whole set of functions like read/write/connect/accept etc...

I like the idea of being able to schedule coroutines on multiple threads though. In librinoo, I have the concept of 'scheduler'. A scheduler handles a set of coroutines and you can one scheduler per thread (that I called 'spawning').

Those libs are just awesome to quickly create scalable network programs. Well done.

[ Parent | on HN ]

Re:Lightweight concurrency library for C, featuring symmetri... by jdmt on Friday October 18, 2013 @02:04PM (#6572908)

Why do you do things like:

  assert(doSomethingThatChangesState() == 0);

throughout your code? I thought the point of assert was for debugging purposes and you should never change program state inside the assertion.

[ Parent | on HN ]

Re:Lightweight concurrency library for C, featuring symmetri... by halayli on Friday October 18, 2013 @02:29PM (#6573113)

I prefer to fail as soon as possible. I use asserts in places where there is no good way to recover from a failed invariant.

[ Parent | on HN ]

Re:Lightweight concurrency library for C, featuring symmetri... by jdmt on Friday October 18, 2013 @02:40PM (#6573181)

Failing immediately is certainly an easy way to handle unrecoverable errors. However, it seems as though your library assumes NDEBUG is never defined. Maybe you should make your own function rather than using assert()?

[ Parent | on HN ]

Re:Lightweight concurrency library for C, featuring symmetri... by halayli on Friday October 18, 2013 @02:54PM (#6573281)

The asserts are in the .c files. Defining NDEBUG in your program won't change anything in lthread because the library was compiled without NDEBUG defined.

If you want to define NDEBUG when compiling lthread, that's up to you.

[ Parent | on HN ]

Re:Lightweight concurrency library for C, featuring symmetri... by sebcat on Friday October 18, 2013 @03:24PM (#6573469)

If you compile

assert(foo(bar) == 0);

with NDEBUG, foo will never even be called. I've seen some funky bugs from this in the past, like people calling malloc inside an assertion... Works great during dev, release build has NDEBUG defined, no test coverage... You get the picture.

A better idea would be to capture the return value in a var and do the assert on the var.

[ Parent | on HN ]

Re:Lightweight concurrency library for C, featuring symmetri... by halayli on Friday October 18, 2013 @04:12PM (#6573754)

Yes I understand that foo() won't be called if you defined NDEBUG. But when compiling lthread, NDEBUG is not defined anywhere in the code / makefiles so it's guaranteed to be called and I want to assert the returned value.

[ Parent | on HN ]