lkml.org 
[lkml]   [2000]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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.
www.fsmlabs.com www.rtlinux.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.191 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site