[lkml]   [2000]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: SCO: "thread creation is about a thousand times faster than on native Linux"
    On Thu, Aug 24, 2000 at 02:01:55PM +0200, Andi Kleen wrote:
    > POSIX wants to send the signal to the first thread in the group who
    > doesn't have it blocked.

    To _any_ thread in the group that does not have it blocked.

    > Several signals are special cased in POSIX, e.g. SIGSTOP, and need to
    > handled by all threads in the group.

    I think that logic needs to be in the root thread.

    > Here is my braindump. I would appreciate any comments.
    > For good behaviour you need a shared sigprocmask(). (I just ran into a
    > situation where shared signal blocking would have been very useful on Linux).
    > You basically want to protect your data structures that could be accessed
    > by signals against signals send to any thread, otherwise sigprocmask
    > are pretty useless.

    POSIX says sigprocmask has unspecified effect in multithreaded processes.
    So you basically want a polite error message.

    > To complicate it the Single Unix spec is vague here. sigprocmask in a
    > multithreaded process is undefined. I think it only makes sense to have
    > it shared for all threads in the group, otherwise you simply cannot use

    I think it makes sense that it fails or that it is done in user mode.
    It's actually not too hard to do in user mode, if we have a root thread.

    > Some programs want waitpid() to return something consistent when the last
    > thread goes away. In your case that would be the tid, that could be set
    > e.g. via prctl similar to PR_DEATHSIG.

    I don't get this: The only waiter would be the process that cloned the
    thread. The waiter then knows its own pid already so ...

    > On the topic of waitpid: One reason why LinuxThreads uses that wasteful
    > ThreadManager-does-the-clone construction currently is that there is no
    > easy way to redirect the waitpid notification to arbitary processes.
    > LinuxThreads needs to see thread deaths though and not miss them when
    > the creating thread died earlier. With tids it would be best if waitpid()

    I don't get this either: If we have a "root" thread that acts like a daemon,
    then why would we ever need to redirect?
    If I recall correctly, POSIX blows away threading over a fork anyways, so
    any children we could wait for must be generated by pthread_create and
    this can easily be made to use a SYBLING flag in clone.

    > Another thing would be shared credentials. I'm sure there are portd
    > programs who have security bugs on Linux because they expect setuid() to be
    > process global, and it is local. Unfortunately that's more ugly to get right,
    > you would need separate reference counted credentials structures to get
    > atomic behaviour for system calls (they cannot see half changed credentials
    > or eat credentials changes after sleeping).

    Userspace with kernel assist:
    for each pid in threadset do setuid_pid(pid,uid);

    Victor Yodaiken
    Finite State Machine Labs: The RTLinux Company.

    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 12:38    [W:0.025 / U:54.168 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site