[enqk]

Care to explain further?

In my experience of using protothreads, only the functions using the protothread macros need to be written in a special way:

   - passing a context object
   - being careful of variable initialization/blocks 
     in order not to work on unitialized memory.

while all the other ones can stay plain C functions.

[_yosefk]

Sure, if none of these C functions tries to yield, or calls a library function trying to yield. In fact, the problem isn't that they can't be plain C functions, but that they must be plain C functions :)

Why would functions called by "lightweight threads"/"coroutines"/whatever want to yield? One example is, they want to wait for an event - an I/O request completion or a computation offloaded to an accelerator or whatever - without having to return all the way back to the event loop.

[enqk]

I must admit that this property attracted me to protothreads, since there is a clear demarcation between coroutines (through the presence of a protothread argument) and plain C functions.