DragonFly kernel List (threaded) for 2004-02
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: lkwt in DragonFly
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@xxxxxxxxxxxxxxxxxx>
http://www.energyhq.es.eu.org
PGP Key: 0xDC8514F1
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]