FFI: number of worker threads?

[skaller]

On Wed, 2006-06-21 at 17:55 +0100, Duncan Coutts wrote:

> So I'd suggest the best approach is to keep the existing multiplexing
> non-blocking IO system and start to take advantage of more scalable IO
> APIs on the platforms we really care about (either select/poll
> replacements or AIO).

FYI: Felix provides a thread for socket I/O. Only one is required.
Uses epoll/kqueue/io completion ports/select, depending on 
OS support.

Similarly, there is one thread to handle timer events.
We're working on a similar arrangement for asynchronous file
I/O which many OS provide support for (Windows, Linux at least).

There are only a limited number of devices you can connect
to a computer. You can't need more than a handful of threads,
unless the OS design is entirely lame .. in which case you'd
not be trying to run high performance heavily loaded applications
on that system in the first place.

Our biggest headache is non-reentrant APIs
such as Open GL which are only re-entrant on a process basis,
this doesn't play with with pre-emptive threading and it's
also not good for cooperative threading. The only real solution
here is to run a server thread and a thread safe abstraction layer,
which cooperate to do context switches when necessary. 

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net