I'm always on the close lookout for stuff like this because until recently I maintained some C code that really ought to use threads but can't afford the extra

I'm always on the close lookout for stuff like this because until recently I maintained some C code that really ought to use threads but can't afford the extra stacks/context switching. Here's my current view: - "Protothreads" are just the old switch statement coroutine trick. Local variables do not persist across async switches - this is expected and not surprising but that doesn't make it any less unnerving, it would be very easy to accidentally introduce very hard-to-debug problems in code using this technique. None of the author's examples expose this limitation! - async.h seems to be just the addition of a per-protothread structure where you can store your state (where the old coroutine trick typically has people just using static variables). This improves things a little but the author's examples still don't highlight the major issue that local variables don't persist. I suspect they didn't mention it because it seems so obvious, but that doesn't mean it isn't important. I worked for about 2 years on code that's perfectly suited to these techniques (i.e. software that manages inherently parallel procedures, but that cant use actual threads), spent lots of time considering them, but in the end I think it's just better to manually manage your flow control. You end up with state coming in and out of functions as struct members (which is exactly the main idea of async.h IIUC) and the flow of your code doesn't look very naturally like the flow of the procedures it's actually managing. The solution IMO is just to code carefully, write comments, and draw diagrams. My C files like this start with a couple pages of prose outlining the operation of the HW they're interacting with (if it was not interacting with HW, it would probably describe the protocol it's implementing, or the user interaction it's facilitating), and how that relates to the design of the SW in the file. Once you have that, I think the reader can see how the slightly unnatural function boundaries map onto elements of the broader system. Sorry to be negative, these headers are cool and interesting and I'm glad people invent them. I just don't think we should use them in important software.