Messages in this thread | | | Subject | Re: Slow pthread_create() under high load | From | Ulrich Drepper <> | Date | 28 Mar 2000 12:13:32 -0800 |
| |
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.
> 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 realy hae currently not the slightest idea how to implement it. The consequence is that you currently cannot stop multi-threaded applications with ^S. Only the initial thread is stopped.
> 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
- see if there is none, see whether any thread is not blocking it; if yes devliver it
- 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
- otherwise call threads ignore the signal and it has to be discarded
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.
-- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------
- 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/
| |