Re: Coroutines and blocking IO

[Eric Jacobs <eric@...>]

On Thu, 26 Jan 2006 19:26:18 -0500
Jon Smirl <jonsmirl@gmail.com> wrote:

> 
> That's what I find neat about the Ruby solution. From Ruby the IO
> looks like it is synchronous. All of the select/poll and IO thread
> logic is hidden in C code and invisible to the Ruby programmer. There
> is no Ruby API for async IO.

This is pretty easy to do in Lua. All you have to do is write a
scheduler, and then make sure that when one of your scheduler's
clients accesses 'socket', they see the wrapped version of the
functions. Thus, the sync/async translation _is_ (mostly) invisible
to them, as users of the socket library.

The reason I say mostly is the only deficiency I've found in using
Lua in this style: you can't intermingle a coroutine-based scheduler
with other uses of coroutines in the code (for example, tree walking
using coroutines.) The yield messages get crossed. I would imagine
that Ruby, having support for full first-class continuations,
wouldn't have this problem.

I would still disagree though, even if Lua had full continuations,
that the scheduler logic should be pushed up into the Lua core. There
are good reasons for handling it as an application-level library;
for example, you may be working with a GUI library that requires you
to call its GetFooEvent() function rather than jumping in and
attemping to do select/poll yourself. Put another way, it is not
to be presumed that we want the sync/async logic hidden from _all_
of the application code; just the code that does not want to concern
itself with it.

-Eric