[Nel] NeL Network Engine

Mon, 26 Feb 2001 19:50:35 +0100

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 ...
+
+