>-----Original Message-----
>From: Matthias Buelow [mailto:mkb@mukappabeta.de]
>Sent: Monday, June 11, 2001 5:06 PM
>To: Stephane St Hilaire
>Cc: netbsd-users@netbsd.org
>Subject: Re: NetBSD is not Linux


>Stephane St Hilaire writes:

>>I'm not sure what is your point... Is 4090 processes an insufficient
number
>>? Does a program made up of one executable/two threads require more
>>ressources and run slower than a program that forks itself up and uses
twice
>>the amount of memory ? Are you saying that threads are not useful in an OS
>>and should never be a part of NetBSD ? 

>The problem wojtek was probably hinting at is, since lignux maps
>each user library thread onto one kernel process entry, running
>applications which use many threads (like, several thousand[1]) is
>prohibitive, from a resource consumption pov, and often simply not
>possible, when the number of threads is larger than the max number
>of proctable entries.

I got that but 4090 is still a large number and I don't think it has been a
limiting factor yet for Linux. 


>Normally, thread libraries multiplex many user threads onto a few
>system threads so that problem is not so serious there.  This seems
>not to be the case with the linuxthreads libraries, however.


>--mkb

>[1] You might say applications with several thousand threads do
>not exist?  
I hope and pray that they don't.


>Think of server applications that don't use the
>poll(2)/select(2) mechanism for i/o multiplexing and instead use
>a single thread per client connection.  Such a thing should be
>fairly common in the Windoze "server" world,

Actually it's a lot more typical in the unix world where either threads are
not available or a lot of the server/application code still being used and
distributed was written before they were. You usually end up having one
process per client connection (all inetd services run like this).

The Windoze world probably has a lot of problems but for one thing it has a
unified  synchronization object model that goes far beyond what select
(which is of course present too) provides. You can use a grab bag of mutexes
semaphores or others within a WaitForMultipleObjects call for example. Still
a bad programmer can program a one client per thread (or one process per
client on NetBSD) design if he doesn't know better but it's not all that
more typical on one platform that the other.

Anyway no matter the OS thousands of threads or processes on a single
machine ain't a good idea (and is poor design).

Steph