[Nel] NeL Network Engine

[Vincent Caron]

Bernard Hugueney wrote:
> 
> Well, I'm as far as possible from a threads expert, but I think that
> what makes LinuxThreads special is that they are system threads (vs user
> threads) maybe heavier, but making use of SMP, so basically, I think
> the max nb of threads is very much system dependand (SMP?).

Threads are indeed system tasks internaly, and they are scheduled as such.
The number of tasks and/or threads is only limited by NR_TASKS at compile
time in Linux. And yes, the scheduler is not really effective at managing
more than 1000~2000 tasks, and doesn't provide enough semantics to
optimize thread use. This is rather a matter of design, and you could
without great trouble design a Linux scheduler that handles a bunch of
threads the way you expect it, but as far as I known, only the real time
versions of Linux (such as RTlinux) have played with this part of the
Linux code. Now about SMP, Linux does spreads threads over the available
CPUs to optimize parallelism, but there's no limitation. And you'll only
get a speed up on SMP machines if you really have parallel threads (ie.
not a thread join every 10 lines !).

I guess we're raising the question of time sharing (or 'multiplexing', sounds
cool :)). You can let the OS do it for you and use threads everywhere : BeOS
is a good example since everything than can receive events is in a thread.
You can do it all by yourself : use one process and dispatch the incoming
events to functions (ie. WinProc). Why you would use one more than the other
is a matter of design, and also depends on the type of application and the
OS you use. The anwser is really not simple and won't certainly fit in a mail,
but I must admit I don't have good pointers to give ...