Re: coroutines — avoid the busy wait

["Javier Guerra" <javier@...>]

On 12/24/07, Mildred <ml.mildred593@online.fr> wrote:
> So I thought about using coroutines and the problem is that nothing may
> happen for a long time. So my scheduler would just go from a thread to
> another just to check there is nothing to do ... a busy wait.

the way coroutine schedulers do it is setting up a table of 'blocked'
coroutines, keyed by the blocking event of each coroutine.  that way,
when the main loop of the scheduler  gets an event, it can fetch the
corresponding coroutine and resume it.

of course that means that the scheduler has to handle _every_ kind of
event that you might want to block for.  in the 'original' Unix
philosophy, most event-like APIs use a blocking file.  in linux kernel
development threads you can frecuently see discussions about the
userland interface for new subsystems, and most of them use a file
handle to identify the kernel objects.

the offending events are mostly those that come from userland
libraries; most notably database APIs. they simply state that this or
that function call might block; or not even tell, assuming the user is
aware that most DB operations are reasonably quick but fundamentally
unbound in time.

> I don't know how I could solve that. I can't use the method described
> in the PiL (that calling a function that will sleep until a socket
> receive data) since the threads are triggered by different kind of
> events.

i have thought about that too, and the only solution i´ve come up is
declaring all current blocking APIs 'inconvenient'.  there should be a
single 'base' API to declare 'background' tasks and a single blocking
call to wait for _any_ event.

<selfpromotion>
to put my code where my mouth is, i wrote the Helper Threads Toolkit.
it's a common base of code to be used by any module writer, making it
relatively easy to put any blocking C code into a 'helper thread' that
might block while the Lua code goes on. When unblocked, an event is
put into a queue to be picked up by a single wait() function called by
the Lua scheduler.

so far, i've written simple (but working) libraries for timers, file
and TCP R/W, and started (but still unfinished) an SQLite binding.
also there's a very small but complete Lua scheduler
</selfpromotion>

another way to do it, is to multithread your Lua code. Lua Lanes seems
to be the most active project these days for this.  the only downside
is that you have to use message-passing to communicate between
threads.


-- 
Javier