Lines Matching refs:signal

31 Re:   New World signal handling
38    1. signal handlers are process-wide global state
39    2. signal masks are per-thread (there's no notion of a process-wide
40       signal mask)
41    3. a signal can be targeted to either
46 1 is why it is always a bug to temporarily reset a signal handler (say,
51 3 is responsible for some of the nitty detail in the signal stuff, so
53 signal is targeting the whole process, its only ever delivered to one
54 particular thread; there's no such thing as a broadcast signal.)
60 signals are pending for it.  poll_signals grabs the next pending signal
61 which the client signal mask doesn't block, and sets it up for delivery;
63 rather than have them delivered to a signal handler.   This means that
65 the signal handlers; we can just poll for them synchronously when
71 they need to be always unblocked, and the signal handler is called when
73 call poll_signals after any syscall which may raise a signal, since
74 signal-raising syscalls are considered to be synchronous with respect to
75 their signal; ie, calling kill(getpid(), SIGUSR1) will call the handler
78 The one time when the thread's real signal mask actually matches the
79 client's requested signal mask is while running a blocking syscall.  We
81 the right signal-interrupts-syscall semantics.  The tricky part about
83 set-signal-mask-and-block-in-syscall mechanism, so we need to fake it
87 point the syscall got to when the async signal happens.  By keeping the
92 determining which thread should get a signal, what the correct action
95 per-signal special cases (which is, roughly, signals 1-32 are not queued
98 BUT, there's another complexity: because the Unix signal mechanism has
101 instruction), we can't block a signal for one form and not the other. 
106 To handle this case, there's a small per-thread signal queue set up to
108 whole process" - a hack, I'll admit).  If an async SIGSEGV (etc) signal
111 what signal to deliver next.  These queues are only manipulated with
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
125 The other is that if the thread which recieves the signal is not running
127 syscall to complete), then the signal handler will grab the run_sema
129 an async signal asynchronously is during a blocking syscall, this should
137 which are used to signal a problem while fetching an instruction, or by
147    1. the process is ignoring the signal (SIG_IGN)
149    3. the process has a handler for the signal
156 client-specified signal handler case.
158 The default handler case is relatively easy: the signal's default action
162 thread-specific signal death. Terminate comes in two forms: with
170 Delivering a signal to a client-side handler modifys the thread state so
171 that there's a signal frame on the stack, and the instruction pointer is
173 completely different signal frame formats: old and RT.  While in theory
179 while setting up the signal frame.
182 and rt_sigreturn, which a signal handler will use to resume execution.
193 or exception throwers) recognize the existence of a signal frame by
195 two specific signal return sequences, it knows its a signal frame. 
196 That's why the signal handler return address must point to a very
209 the master_tid hasn't exited, then this signal is ignored.  It isn't
211 SIGVGCHLDs to build up, eventually clogging the kernel's signal delivery
253 Re:   Fwd: Documentation of kernel's signal routing ?