[lkml]   [1998]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectThread implementations...
       Date: 	Thu, 18 Jun 1998 11:37:28 -0700 (PDT)
    From: Dean Gaudet <>

    [ 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 ;-)

    David S. Miller

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

     \ /
      Last update: 2005-03-22 13:43    [W:0.023 / U:39.516 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site