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/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:13 EST