Re: LUTask (was Re: LuaSocket, LTN12 and coroutines: how to? (long post)) long as well...

[skaller <skaller@...>]

On Sun, 2005-01-30 at 11:57, PA wrote:

> The run loop runs only once through the list... this is somewhat on  
> purpose... as I would like to avoid the run loop "busy waiting" on  
> something to execute even when strictly nothing is going on at all...  
> ideally I would like to have some sort of "event" driven system... but  
> I have no idea how to do that yet... 

Felix does it like this: when a coroutine yields it
flags whether it is a 'polite yield' or a 'blocking read'
or a 'dead coroutine'.

What you do then is keep *two* lists of coroutines,
'running' and 'blocked'.

You cycle through the 'running' list until it is empty.
A coroutine which is 'dead' is deleted, a coroutine
which is 'blocked' is moved to the 'blocked' list.

After the 'running' list is empty, you fetch
can event out of the event queue. You may feed
this queue with any variety of sources such as
pre-emptive threads, some kind of polling,
LuaSocket, or whatever.

When you get an event out of the queue,
you have to decide which coroutine (s) to
send it to. You also have to choose how to
send the event data -- argument passing is
one way, storing the even in a per-coroutine
table is another .. etc.

So you organise to make the coroutines which
the event 'unblocks' resume by sending
them the data somehow and moving them
back into the 'running' list.

This way -- you execute coroutines until
all of them block, then the scheduler
also does a blocking read on the even queue
to get an event, and dispatches it to
one or more (or no) coroutines.

In Felix, the scheduler can also *create*
new threads if it gets an event for which
there is no registered coroutine, in particular,
a coroutine can create another coroutine
by posting a 'create coroutine' event into
the event queue.

This algorithm is very simple, it is maximally
efficient, it is entirely event driven,
and it is totally unfair. It is therefore
well suited to high performance hard
real time applications, but not so good for
soft real time (where fairness is sometimes
required).

Note the algorithm tells you nothing about
how you choose which coroutine(s) to run
nor how you send the coroutines event data.


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net