[lkml]   [2000]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Slow pthread_create() under high load
    On Tue, Mar 28, 2000 at 01:06:08AM -0700, Richard Gooch wrote:
    > Because the kernel doesn't make this easy. The kernel has the concept
    > of "tasks", which don't map well to POSIX threads. The kernel doesn't
    > distinguish between "processes" and "threads" like POSIX does.
    > Everything is just a task. Tasks can share some things (FS, files,
    > VM), but they can't (yet) share PIDs (probably never), signal queues
    > and other things required for POSIX compliance.

    IMHO, at least sharing PIDs would be a useful thing. Signal queues
    would be nice, but there are other ways to deal with that.

    > You could probably write a native Linux threads library (lthread_*()
    > anyone?) which was just as easy to use and powerful, and didn't
    > require buggering the kernel. So from the point of view of the kernel
    > community, there is reluctance to throw complex and ugly
    > POSIX-specific support code into the kernel, for the sake of
    > compliance with an ill-considered standard. Leave the problems to
    > user-space, and hence the performance problems people mention.

    Hmm... it would be nice if there was a thread library that let me

    1) Solid support for signals, including real-time signals and such
    interesting RT signal extensions that normally require
    POSIX-threads. (Indeed, at least in the POSIX world queue'd signals
    seem to be the way to go, and I'd hate to handle signals any other way
    in a threaded world.)

    2) Support for high-speed synchronization structures. In particular,
    one should be able to do thread synchronization much more efficiently
    than processes synchronization.

    3) Was integrated into the glibc library, so I didn't have to worry
    about reentrancy problems.

    This all seems highly unlikely to me, and this is why I really would
    like to have a good POSIX-threads implementation for Linux. Perhaps
    I'm wrong though. Can someone point me to an implementation of threads
    on Linux that comes close to the above criteria? If such a beast
    doesn't exist, it seems to me that there would be some advantages to
    considering the kernel support for POSIX threads option. These

    - Already integrated with glibc.
    - Well defined specification that is integrated with other POSIX
    features (such as signals).
    - Standards compliance is always a nice thing, particularly for making
    portable software.

    There was a time when the mantra for Linux was, "when given a choice
    between following the standard and doing something cool, I followed
    the standard." Perhaps that time has passed, but I think it's worth
    reflecting on the merits of that argument and how helpful it's been
    for Linux to date.

    It appears to me that by NOT being POSIX compliant in this area, you
    limit the ability to leverage many of POSIXes other features in a
    threaded program in general. Furthermore, you require a LOT of
    reworking in userland libraries and such undoubtedly creating


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

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