Andrew Piskorski wrote:
On Fri, Jul 15, 2005 at 04:21:05PM +0300, Cariotoglou Mike wrote:
memory and cpu-wise. on Linux, this is nothing, it can handle it easily.
otoh, 500 threads for windows is business as usual, but threading on
Linux, is , I hear, iffy at best.
Linux runs multi-threaded apps (e.g., AOLserver) quite well, and has
for many years - since at least 2000 or so, probably earlier. My
understanding is that the old LinuxThreads implementation had some
pretty ugly bits, but it worked. NPTL is much better, and is standard
with the Linux 2.6.x kernels.
Some architectures permit, or even encourage, multi-threaded design. It
can be done obviously.
However, Dr. Hipp still has a point. One thread can trash another's
address space. They share code, global data, the heap (generally) and
system object handles (files, sockets, IPC devices ( and weird crap like
"Desktop" and "Mutants" on windows). The only non-shared things are the
stack, TLS (thread local storage) and per-thread CPU context. Even
then all of those things can be trashed by other threads in the same
process. Unless you can _prove_ that your code won't do this (and all
code that you call, including system DLLs / SOs) then you are taking a risk.
Personally, I prefer multi-threaded code. I like to write it and I like
to debug it. I ship it to customers. Your millage may vary.
And yes, Linux threads used to be very unstable. I've only used Linux
threads once, and it was on a recent 2.6 kernel, so I never experienced
the problem(s).
