Lines Matching full:signals
57 all its signals blocked (all but the fault signals: SEGV, BUS, ILL, etc).
60 signals are pending for it. poll_signals grabs the next pending signal
62 it uses the sigtimedwait() syscall to fetch blocked pending signals
64 we avoid the complexity of having signals delivered asynchronously via
68 Fault signals, being caused by a specific instruction, are the exception
80 have to set things up to accept signals during a syscall so that we get
88 window where signals are actually unblocked very narrow, the number of
95 per-signal special cases (which is, roughly, signals 1-32 are not queued
96 except when they are, and signals 33-64 are queued except when they aren't).
100 signals raised by kill(), and synchronous faults raised by an
107 deal with this case (I'm using tid 0's queue for "signals sent to the
110 VG_(poll_signals) also checks these queues for pending signals to decide
112 *all* signals blocked, so there's no risk of two concurrent async signal
120 signals concurrently. One is that a signal handler is set up to block a
121 set of signals while the signal is being delivered. Valgrind's handlers
122 block all signals, so there's no risk of a new signal being delivered to
130 be all the time. (And since synchronous signals are always the result of
134 Valgrind will occasionally generate signals for itself. These are always
142 That all explains how signals come in, but the second part is how they
151 In general, VG_(deliver_signal) shouldn't be called for ignored signals;
187 pending signals after the old frame has been cleaned up, since there's a
188 requirement that all deliverable pending signals are delivered before
190 live-lock on signals, but that's what would happen running natively...
200 What else. Ah, the two internal signals.
278 NPTL we also share other stuff like signals, etc. The 'pid' in Linux is
288 most of its work by propagating signals manually between threads.
