[lkml]   [2000]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Slow pthread_create() under high load
Date 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

---------------. drepper at ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at `------------------------

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.045 / U:0.604 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site