> nuke@bayside.net wrote:
>
> > And the fact is that both Chapman and Dawson [IE4/solaris developers] > have grown quite comfortable shuttling back and forth between the
> > worlds of Windows and UNIX. "It's amazing to me how far UNIX has to go
> > today to catch up to NT," says Dawson. "Take, just for one example,
> > threading support. UNIX still has benefits, but NT is just a lot more
> > full-featured."
>
> OH HAHAHAHA!!! I haven't laughed so much since the time someone fell on
> a wall and mangled his private bits. Who are Chapman and Dawson kidding?
> HAHAHA!! I can't believe these two are Solaris developers and yet come
> out with this tripe?!
Have you worked with threads under NT and worked with threads under, say,
linux? Linux is in the dark ages as far as threads go. There's
linuxthreads, but to debug them you need to patch the kernel. You don't
get core dumps without another kernel patch. gdb doesn't support it all
directly, unless you patch it. None of that has made it into the main
distributions.
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). There's a paper from sun regarding solaris
pthreads, see
<http://www.arctic.org/~dgaudet/apache/2.0/impl_threads.ps.gz> for a copy
of it. You may also want to visit the JAWS papers at
<http://www.cs.wustl.edu/~jxh/research/research.html> for more discussion
on various threading paradigms.
Have you read my posts regarding file descriptors and other unix semantics
that are "unfortunate" when threading? They're not the end of the world,
but it's really obvious once you start digging into things that much of
unix was designed with a process in mind. 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. 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. "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.
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.
NT may not be stable, but there's a lot of nice ideas in there. Don't
just shoo it away saying "pah, that's microsoft's piece of crap". DEC had
their hand in some of the architecture.
Dean
P.S. And now I'll go ask myself why I'm even responding to an advocacy
thread on linux-kernel.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu