Not logged in
Log in now
Create an account
Subscribe to LWN
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
Threads on the other hand offer neither. Locking requirements makes them hard to get right, and they eat up a lot of resources making e.g. DoS attacks on thread-based web servers easy.
If you combine coroutines with multiple worker processes, it also allows you to use multiple cores.
I recently did a MIT licensed co-routine library for C/C++:
Posted May 8, 2012 17:39 UTC (Tue) by endecotp (guest, #36428)
Boost has a proposal for a coroutine library by Oliver Kowalke which should be reviewed sometime in the next few months. See e.g.
It would be great if you could write a review when the time comes - getting the view of someone with relevant experience is obviously very useful.
Posted May 9, 2012 20:42 UTC (Wed) by kjp (subscriber, #39639)
Posted May 8, 2012 17:46 UTC (Tue) by juliank (subscriber, #45896)
Posted May 8, 2012 17:59 UTC (Tue) by fuhchee (subscriber, #40059)
Despite that advantage, pure message-passing-based concurrency hasn't taken the CS world by storm.
Posted May 8, 2012 18:50 UTC (Tue) by juliank (subscriber, #45896)
Posted May 8, 2012 19:07 UTC (Tue) by wahern (subscriber, #37304)
Posted May 8, 2012 19:37 UTC (Tue) by juliank (subscriber, #45896)
Posted May 8, 2012 20:18 UTC (Tue) by wahern (subscriber, #37304)
Limbo succeeded Alef, and Go seems to have succeeded Limbo. But I'll admit this is all just largely opinion.
But more to the point, Plan 9 never touted intraprocess message passing. If you read any of the papers, when they talked about parallelism they spoke about their rfork() system call (which may have inspired Linux' clone syscall; OpenBSD's rfork is clearly derivative of Plan 9). Alef, and later Limbo, was where all the experimentation into messaging passing went, and I think my comparison to Awk v. Unix is apt. To see where I'm coming from, just read their own description and emphasis: http://www.cs.bell-labs.com/sys/doc/9.html
Posted May 9, 2012 16:39 UTC (Wed) by hanwen (subscriber, #4329)
Posted May 9, 2012 18:51 UTC (Wed) by juliank (subscriber, #45896)
Posted May 11, 2012 13:43 UTC (Fri) by hanwen (subscriber, #4329)
Posted May 8, 2012 20:54 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
In niche areas Erlang (built on message passing) is quite popular.
Posted May 8, 2012 19:03 UTC (Tue) by endecotp (guest, #36428)
How do you implement your message passing? Most likely it needs some form of locking internally.
I would express it this way: don't try to implement your multi-threaded application using ad-hoc locking / synchronisation. Instead put all of the locking into some concurrency building blocks and restrict your inter-thread communication to only those building blocks. Message passing is one possible set of building blocks, but there are others.
Posted May 8, 2012 19:19 UTC (Tue) by robert_s (subscriber, #42402)
Posted May 9, 2012 2:12 UTC (Wed) by jamesh (guest, #1159)
Things are a bit different if you're talking about cooperative multi-tasking within a single application though: if the application is controlling all the co-routines, then those sort of bugs should be predictable and fixable. Co-routines can greatly simplify some programming tasks: letting you use the stack to manage state, while not having to deal with the complexities of concurrent execution in the same address space.
Posted May 9, 2012 12:37 UTC (Wed) by geertj (subscriber, #4116)
Exactly - this is the key difference. And it's not like the different threads in a multi-threaded program don't need to cooperate. They can just as easy starve each other if e.g. they do not correctly cooperate in locking.
Posted May 8, 2012 20:11 UTC (Tue) by valyala (guest, #41196)
Posted May 8, 2012 20:31 UTC (Tue) by wahern (subscriber, #37304)
I've been writing event-oriented and thread-oriented C apps for over 13 years. Using makecontext was useful then, but not so much today.
Re: getcontext/setcontext alternatives
Posted May 9, 2012 2:53 UTC (Wed) by scottt (subscriber, #5028)
Posted May 9, 2012 11:20 UTC (Wed) by geertj (subscriber, #4116)
One trick that is sometimes used is sigaltstack() + setjmp(). However i would argue this is actually less portable than writing assembly (the assembly you refer to above is not OS specific, it is only architecture specific and the same function it works on Linux, Mac OSX and Windows).
In the best case, we would get a working and not-deprecated makecontext() function from libc at some point. Also we would need to get an extended longjmp() that allows for code injection in the target co-routine (for propagating exceptions in C++).
Posted May 11, 2012 23:53 UTC (Fri) by jwakely (subscriber, #60262)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds