Messages in this thread | | | Date | Thu, 18 Jun 1998 19:41:03 -0700 | From | "David S. Miller" <> | Subject | Thread implementations... |
| |
Date: Thu, 18 Jun 1998 11:37:28 -0700 (PDT) From: Dean Gaudet <dgaudet-list-linux-kernel@arctic.org>
[ 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
| |