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

[Mike Pall <mikelu-0501@...>]

Hi,

Mark Hamburg wrote:
> Interesting. In an interactive environment where one had a thread that ran
> for a while perhaps being polite enough to do non-blocking yields but not
> blocking, this would have the issue that it won't revisit the event queue.
> On the other hand, the dispatcher could watch a clock or wait for a signal
> from a timer to decide that we should visit the event queue even if the
> running queue is non-empty.

The easiest way to solve the runq vs. eventq problem is to redefine it.

Add virtual events that can be user-triggered and give them their own queue.
Then do round-robin checking of all user and system queues (virtual events,
tickers, timers, file events, other system events, ...). Add a barrier to
each queue before delivering its events, to avoid deadlock.

So whenever a thread is CPU-bound and needs to do polling yields, yield
an already triggered virtual event instead. The thread will be resumed
after all other events have been delivered. Provided the CPU is not locked
up for too long, you get nice and smooth background threads this way.

Generic virtual events (decoupled creation and triggering) are handy for
many other things, e.g. handling synchronous system callbacks or syncing
with native threads.

Priorities can be emulated by allocating varying PLL-adjusted timeslices
to each background thread (measure the time delta and adjust a loop
counter). A lot easier than implementing a full-blown priority scheduler.

At least this is what I've done and it works well.

[Sorry, I can't release this stuff yet -- I need to finish other things
 first before I can get back to working on it.]

Bye,
     Mike