[ My commented is not directed to Dean or anyone in particular,
there were just some things I wanted to state in general wrt.
to the issues raised here. ]
Even with the debugging problems solved, linuxthreads are heavier
than solaris pthreads or NT fibers. Both of those use a
multiplexed user-level and kernel-level threading system which
results in fewer kernel context switches. In userland a "context
switch" is just a function call. But we'll see this solved with
Netscape's NSPR which was released with mozilla -- it provides a
multiplexed threading model (that particular model isn't ported to
linux yet).
Making threads under Linux not be multiplexed at the user side was a
conscious design decision. Doing it half in user half in kernel (and
this is the distinction being mentioned when Solaris nomenclature
speaks of kernel bound and non-kernel bound threads) leads to enormous
levels of complexity for fundamental things such a signal handling.
The folks at Solaris spent a lot of time fixing bugs that were solely
getting signals right in their threads implementation. Keeping track
of what the kernel sends to a "kernel bound thread" and making sure
the right "pure user thread" within gets that signal correctly is
tricky buisness. It's complex and hell to get right. (search the
Solaris patch databases for "threads" and "signals" to see that I'm
for real here about how difficult it is to get right)
This is why we do it the way we do it.
For example, on NT there is absolutely no problem with opening up
10000 files at the same time and holding onto the file handles.
This is exactly what's required to build a top end webserver to get
winning Specweb96 numbers on NT using TransmitFile.
Yes, I know this.
On unix there's no TransmitFile, and instead we end up using mmap()
which has performance problems. Even if we had TransmitFile, 10k
file descriptors isn't there.
One thing to keep in mind when people start howling "xxx OS allows
such and such feature and Linux still does not yet, why is it so
limited etc.???" Go do a little research, and find out what the cost
of 10k file descriptors capability under NT is for processes which
don't use nearly that many.
I know, without actually being able to look at how NT does it, it's
hard to say for sure. But I bet low end processes pay a bit of a
price so these high end programs can have the facility.
This is the reason Linux is still upcoming with the feature. We won't
put it in until we come up with an implementation which costs next to
nothing for "normal" programs.
"You have to recompile your kernel for that." Uh, no thanks, I
have a hard enough time getting webserver reviewers to use the
right configuration file, asking them to recompile a kernel is
absolutely out of the question.
I actually don't tell people to do this. Instead I tell them to find
a solution within the current framework, and that what they are after
is in fact in the works. If someone can't make it work in the current
framework, Linux is not for them at least for now. A bigger danger
than losing users or apps for the moment due to missing features, is
to mis-design something and end up paying for it forever, this is the
path other unixs have gone down.
Unix multiplexing facilities -- select and poll -- are wake-all
primitives. When something happens, everything waiting is awakened
and immediately starts fighting for something to do. What a waste.
They make a lot of sense for processes though. On NT completion
ports provide wake-one semantics... which are perfect for threads.
Yes, this does in fact suck. However, the path to go down is not to
expect the way select/poll work to change, rather look at other
existing facilities or invent new ones which solve this problem.
Too much user code exists which depends upon the wake-all semantics,
so the only person to blame is whoever designed the behaviors of these
unix operations to begin with ;-)
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu