Messages in this thread | | | Date | Thu, 24 Aug 2000 11:22:51 -0600 | From | yodaiken@fsmlabs ... | Subject | Re: 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/
| |