Eles usam ptrace(2)
, cuja página de manual comenta
While being traced, the tracee will stop each time a signal is delivered, even if the signal is being ignored. (An exception is
SIGKILL
, which has its usual effect.) The tracer will be notified at its next call towaitpid(2)
(or one of the related "wait" system calls); that call will return a status value containing information that indicates the cause of the stop in the tracee. While the tracee is stopped, the tracer can use various ptrace requests to inspect and modify the tracee. The tracer then causes the tracee to continue, optionally ignoring the delivered signal (or even delivering a different signal instead).
e mais tarde:
Note that a suppressed signal still causes system calls to return prematurely. In this case, system calls will be restarted: the tracer will observe the tracee to reexecute the interrupted system call (or
restart_syscall(2)
system call for a few system calls which use a different mechanism for restarting) if the tracer usesPTRACE_SYSCALL
. Even system calls (such aspoll(2)
) which are not restartable after signal are restarted after signal is suppressed; however, kernel bugs exist which cause some system calls to fail with EINTR even though no observable signal is injected to the tracee.
Por padrão, SIGWINCH
é ignorado, mas parece que epoll
é semelhante o suficiente para poll
que o EINTR
é visível para o chamador (mesmo com a reinicialização) .