Re: ANN: Coco -- True C coroutines

[William Ahern <wahern@...>]

On Tue, 2005-08-09 at 01:12 +0200, Mike Pall wrote:
> Revisiting the old arguments against coroutines with a C stack,
> I've made it easy to select the stack size on a per-coroutine
> basis. You can freely mix coroutines with C stacks (of different
> sizes) and coroutines without C stacks.
> 

As discussed with Wim offline, what doesn't work with seperate C stacks
is when used in C applications centered around an event loop. You then
may have to worry from which stack C functions--especially those which
can restart more callbacks--are run from, and that poses a major
limitation. As Wim suggested to me, you can get around that by using Lua
directly from the core event loop (and don't worry about--or do--complex
async flow from C), but that isn't always doable. And, in fact, seems
counter to what Lua is well known for, which is an adjunct to C, not a
replacement.

I think C-based coroutines are useful, but basing Lua's coroutine
support on them _and_ none other means I can't use Lua. I need the
RVM--or similar--patch to employ Lua to any significant degree. I am not
turned off by RVM's solution to restarting C functions. I don't eschew
goto, either. ;) Admittedly, I suppose those attitudes are artifacts of
writing so much asynchronous-I/O code.

I am currently using C coroutines to interrupt Perl VM's in a large
application (libpcl + Linux weak symbol support to yield() on system
calls). I can vouch for the fact that it is not as flexible and useful
as Lua's current, limited, coro support, and certainly no where near as
flexible as the RVM and similar patches could make Lua.

This all reminds me of the async-I/O versus threads holy war--still
ongoing:

	http://www.kegel.com/c10k.html
	http://www.usenix.org/events/hotos03/tech/vonbehren.html

Sure, threads are comparatively elegant. And threads, theoretically, can
give you the same performance. And yet, even Java--a threading
junky--was forced to add the NIO classes by popular demand. For me, the
proper Lua support could allow me to build wholly asynchronous C
applications, but directed by Lua with single control flow logic. Lua
creating and jumping to C stacks takes control away from me, which is
particularly egregious since it's easy enough to do the same thing
myself. And, I should point out, the further seperated the stack
management and Lua proper become, the stronger this argument.