lkwt in DragonFly

Miguel Mendez flynn at energyhq.es.eu.org
Tue Feb 10 13:41:44 PST 2004


Dan Melomedman wrote:

I hear that the main problem with Slowaris is slow fork()/exec(). So
 Slowaris software ends-up using threads in _place_ of processes. 
Furthermore, pthreads are a very generic threads library which is, 
IMHO often used where it shouldn't, and also incorrectly. For 
instance many people blindly assume that creating a bazillion threads
 is okay because they are somehow magically faster than processes,
but
Yes, all that is very nice but it doesn't answer my question. *Why do 
you think 1:1 doesn't work.*

don't even bother profiling. If performance matters, than why are 
they creating more threads than they have CPUs in the first place? 
Also often people choose pthreads over some more convenient thread 
library, and inflict mutexes, race conditions and other problems on 
themselves.
Proper thread programming is not something you learn in 24h. BTDT, 
debugging threaded apps can be a real pain. I don't agree with your 
comment about having more threads that processors, though. Imagine a 
program that does some math calculations and dumps results to disk once 
in a while. You could certainly use IPC to do it, or you could run two 
threads, an i/o thread and a main thread. The i/o thread can be blocked 
on i/o while the other thread[s] keep crunching numbers, even on an UP box.

There should not be anything inherently slow about creating a process
 on modern OSes. If an OS has a slow fork(), that's OS designers' 
problem, not userland programmers'.
Apples and oranges. Threaded programming has its field of application, 
regardless of whether $OS has a slow/fast fork implementation.

Cheers,
--
	Miguel Mendez <flynn at xxxxxxxxxxxxxxxxxx>
	http://www.energyhq.es.eu.org
	PGP Key: 0xDC8514F1





More information about the Kernel mailing list