On Tue, Mar 28, 2000 at 12:13:32PM -0800, Ulrich Drepper wrote:
> yodaiken@fsmlabs.com writes:
>
> > I think you've misunderstood my idea. The data that is copied is
> > simply the information about what threads are announcing an intetion
> > to accept what signals.
>
> Signals sent to the process ID must be distributed to the next
> available thread. Since you (currently) cannot send signals to all
> threads you have to send them to a special thread (= manager) which
> then has to distribute them.
Signals generated by threads within a collection of threads can be
directed to an appropriate destination by looking at the cached signal
state of each thread:
signal(root_process_id,n){
original_signal(thread_allowing(n),n);
}
Signals generated by processes outside the thread group can be directed
to the manager thread which can then use the same mechanism to send
them a second time, this time to the appropriate target.
manager_handler:
got a signal =n
target = thread_allowing(n);
if(!target) save thread data
else kill/sigqueueu signal to thread
> > But the POSIX standard permits such races -- no?
>
> These are races which cannot happen normally. SIGSTOP is not
> propagated to the user level. Therefore there has to be a mechanism
> (would perhaps be possible with ptrace) to find stopped threads and do
> the same for all the others. ptrace() is not really a solution so I
I don't follow this problem. When SIGSTOP is sent to a process all threads
are supposed to stop.
manager_sigstop_handler:
forall threads kill(thread_to_pid(thread),SIGSTOP);
> > Right. All that is taken care of. The mechanism just makes sure that
> > the actual kill or sigqueue call is directed to a thread (process) that
> > is willing to accept the signal.
>
> How do you want to redirect? The kernel does not provide this
> functionality. Again, if I call
>
> kill (ID_of_the_process, SIG)
>
> the implementation has to
>
> - look whether there is any thread waiting for this signal (sigwait);
> if yes, deliver it
We cache that information in our shared address space by wrapping sigwait.
We then use kill or sigqueue to have the kernel deliver it to the
right target.
> - see if there is none, see whether any thread is not blocking it; if yes
> devliver it
Cache that information by wrapping signal and sigqueue
> - see if there is any thread non ignoring the signal; in this case the signal
> has to be cured to be eventually get delivered to the next thread
> unblocking the signal or to be discarded if the last threads marks the
> signals as to be ignored
See above
>
> - otherwise call threads ignore the signal and it has to be discarded
...
Am I missing something here?
> There must be a central handling of the signals. Either in active
> form (= manager) or in passive form as with the shared signal queue.
> I very much prefer the shared signal queue since it also can handle
> SIGSTOP/SIGCONT.
It would still be active, but in the kernel instead of in user space.
Thus, every program would pay a price for Pthreads, whether it used it
or not.
>
> --
> ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
> Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
> Red Hat `--' drepper at redhat.com `------------------------
-- --------------------------------------------------------- Victor Yodaiken FSMLabs: www.fsmlabs.com www.rtlinux.com FSMLabs is a servicemark and a service of VJY Associates L.L.C, New Mexico.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:23 EST