[lkml]   [2003]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?

    All threads within the same process must have the same (single) list of open
    files or bad things will happen. I understand that CLONE_FILES makes this
    true at the time of the clone but I don't know if that keeps this true
    thereafter (e.g I don't know if this is a copy-that or a share-that
    operation). If it doesn't, the some mechanism that does needs to be added.

    If all the co-joined threads of a process share the same file descriptor
    list then /proc/self/fd/* will have unity for the overall process and the
    bulk of the argument disappears completely.

    The reason the threads must share the file descriptor table involves the
    fact that data may, and likely will, flow between the threads. After the
    open(2) call the file descriptor is just data and it will get shared.

    For instance, I have a seriously multi-threaded server application. The
    listen() operation for new clients happens in one thread. When a connection
    is accept()ed I take the request (first bit of data) and match it to the
    service (and therefore thread) that it should be attached too. Then I had
    that socket over to that thread.

    Without the shared file descriptors this would break very badly.

    Conversely, there is virtually no sane model where having a disjoint file
    descriptor list but otherwise conjoined data space makes sense. The file
    descriptors are going to be "tarnishing" the data space if you do this, and
    that is just begging for exploits and "surprises". That is, you will end up
    with little tidbits of data that are conditionally meaningful scattered
    throughout your data space.

    Where you need to have the initial data shared but differing descriptor
    tables you *should* be "stuck" with a classic fork() operation.

    What possible win could you have in having a variable contain a particular
    integral quantity that is a data file open for reading in one thread, a
    mapped segment of memory in another, and invalid in the rest? If you don't
    constrain that behavior now the resulting code that "depends" on this
    behavior will plague this platform for years (see Windows Dynamic Data
    Exchange) and lots of existing expectations for thread behavior will be
    violated day-1 of the release.

    IMHO of course 8-)


    -----Original Message-----
    [] On Behalf Of Linus Torvalds
    Sent: Thursday, October 02, 2003 5:41 PM
    To: Albert Cahalan
    Cc: Ulrich Drepper; Mikael Pettersson; Kernel Mailing List
    Subject: Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?

    On 2 Oct 2003, Albert Cahalan wrote:
    > No. I mean "ban" like we ban CLONE_THREAD w/o CLONE_DETACHED.

    No. Let's not do that.

    We ban only things that do not make sense. That was true of trying to
    share signal handlers with different address spaces. But it is _not_ true
    of having separate file descriptors for different threads.

    I don't imagine anybody cares _that_ deeply about fuser that it can't
    afford to recurse into thread directories.

    And it may or may not make sense to not have a "/proc/<nn>/task/<yy>/fd"
    directory at all if the thread shares file descriptors with the thread
    group leader. That would be a fairly easy optimization.


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

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

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