[MUD-Dev] Thread implementations...

[J C Lawrence]

Read between the lines and think about this one a bit.  Many MUD
servers essentially implement threads internally with their own light
weight looping structures (COLDX's models hase been discussed here in
this regard, see the archvies).  The following gives a more systemic view

--<cut>--
Date:   Thu, 18 Jun 1998 19:41:03 -0700
From:   "David S. Miller" <davem at dm.cobaltmicro.com>
To:     dgaudet-list-linux-kernel at arctic.org
Subject: Thread implementations...

   Date:        Thu, 18 Jun 1998 11:37:28 -0700 (PDT)
   From: Dean Gaudet <dgaudet-list-linux-kernel at 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 at dm.cobaltmicro.com

--<cut>--

I knew the guys at CobaltMicro weren't stupid.

--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...