Thread pooling implementation for Sleep

[Andreas Ravnestad]

It could be nice to implement simple task/command-oriented thread
pooling, ala http://en.wikipedia.org/wiki/Thread_pool_pattern, built
on fork() et al. It should also support distribution (should be
easy?).

I was thinking this could be a nice thing to put into Slumber[1].

Any thoughts/ideas?

-Andreas

[1] http://code.google.com/p/slumber/

[andrerav]

Some thoughts -- Forks (threads) need to maintain state (at least idle/
busy). And, after a fork has finished working, a callback should be a
natural next step?

-Andreas




On Aug 29, 6:09 pm, "Andreas Ravnestad" <andreas.ravnes...@gmail.com>
wrote:

> It could be nice to implement simple task/command-oriented thread

> pooling, alahttp://en.wikipedia.org/wiki/Thread_pool_pattern, built

[Raphael Mudge]

I'd go the route of maintaining a queue and having several worker
threads grab Sleep functions off of it. Keeping a Sleep function as
the unit of execution should simplify things. With Sleep's
continuation support scripters can pause the functions and let them
relinquish the current thread for execution later. In lieu of a
callback I'd just make the worker thread execute the function as-is.
If the function is paused from a previous run then so be it.

inline pause
{
callcc {
# add $1 back onto the waiting for a thread queue.
};
}

I wrote a whole article on continuations and compared them to user-
level threads:

http://today.java.net/pub/a/today/2008/07/24/fun-with-continuations.html

One thing you'll want to keep in mind though, fork() isolates each
thread in terms of variables and everything else. Due to the way
Sleep synchronizes itself, your implementation will need to do the
same. This shouldn't be too bad of a limitation though. When
executing SleepClosures just be sure to set their script owner and
global variables to the threads associated script environment. If
you do this you won't run into any problems.

Hope that helps.

-- Raphael