> On Mon, 12 Jul 1999, Mike Harrelson wrote:
>
> > They may be harder to debug, but that doesn't mean we should just throw them
> > out.
>
> Throwing them out will be pointless, but overuse of threads is harmful.
> The fact that in certain other OS nothing can be accomplished efficiently
> without them is irrelevant.
>
> > Threads can and do make many applications much easier to design and
> > implement without having to go to a slower process/fork()
>
> It's noticeably slower only if processes are constantly created -- but
> the same applies to threads.
True, but context switches between threads are also usually less costly than
between processes. Threads also generally use less memory. Processes and
threads both have their pros and cons though. I suppose it depends on the
application.
> Unix has more advanced interprocess communication than ones in other
> systems precisely because it does not rely on threaded programming.
And also because most Unix IPC were developed before threads were even
thought about. I don't know much about IPC on other systems (like NT) so I
can't comment about it being more advanced.
> > model or a more
> > complicated model using nonblocking I/O with select()/poll().
>
> Where poll()/select() is applicable it's very efficient, and in most of
> cases easy to use unless the concept is completely foreign to the
> programmer.
Poll or select w/ nonblocking IO in server applications can get quite complex.
I've seen examples of identical servers written with process pools, thread
pools, and nonblocking IO(w/ select). The nonblocking versions were by far
the largest and most complex. But interestingly enough, they were also the
fastest!
-- mikeh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/