Hola usuario de nuestra página web, encontramos la respuesta a lo que buscabas, desplázate y la encontrarás aquí.
Solución:
La interrupción de una llamada al sistema por parte de un controlador de señales ocurre solo en el caso de varias llamadas al sistema de bloqueo, y ocurre cuando la llamada al sistema es interrumpida por un controlador de señales establecido explícitamente por el programador.
Además, en el caso de que un controlador de señal interrumpa una llamada al sistema de bloqueo, el reinicio automático de la llamada al sistema es una Opcional rasgo. Usted elige reiniciar automáticamente las llamadas al sistema especificando el SA_RESTART indicador al establecer el controlador de señal. Como se indica en (por ejemplo) la página del manual de la señal de Linux (7):
If a signal handler is invoked while a system call or library
function call is blocked, then either:
* the call is automatically restarted after the signal handler
returns; or
* the call fails with the error EINTR.
Which of these two behaviors occurs depends on the interface and
whether or not the signal handler was established using the
SA_RESTART flag (see sigaction(2)).
Como se insinúa en la última oración citada anteriormente, incluso cuando elige usar esta función, no funciona para todas las llamadas al sistema, y el conjunto de llamadas al sistema para las que funciona varía según las implementaciones de UNIX. el linux signal(7) página del manual señala una serie de llamadas al sistema que se reinician automáticamente cuando se utiliza el SA_RESTART flag, pero también señala varias llamadas al sistema que nunca se reinician, incluso si especifica ese indicador al establecer un controlador, que incluyen:
* "Input" socket interfaces, when a timeout (SO_RCVTIMEO) has been
set on the socket using setsockopt(2): accept(2), recv(2),
recvfrom(2), recvmmsg(2) (also with a non-NULL timeout argu‐
ment), and recvmsg(2).
* "Output" socket interfaces, when a timeout (SO_RCVTIMEO) has
been set on the socket using setsockopt(2): connect(2), send(2),
sendto(2), and sendmsg(2).
* File descriptor multiplexing interfaces: epoll_wait(2),
epoll_pwait(2), poll(2), ppoll(2), select(2), and pselect(2).
* System V IPC interfaces: msgrcv(2), msgsnd(2), semop(2), and
semtimedop(2).
Para estas llamadas al sistema, es esencial el reinicio manual mediante un bucle del tipo descrito en APUE, algo así como:
while ((ret = some_syscall(...)) == -1 && errno == EINTR)
continue;
if (ret == -1)
/* Handle error */ ;
[I haven’t read that APUE thing but the stuff you’re quoting doesn’t look too good]
si mi programa usa una llamada al sistema, sería interrumpido/detenido, si en algún momento el programa capta una señal.
No cualquier llamada al sistema. Solamente algunos las llamadas al sistema son interrumpibles.
(¿El controlador predeterminado también cuenta como captura?)
No.
Por ejemplo, si tengo una llamada al sistema de lectura, que lee 10 GB de datos, cuando está leyendo, envío cualquiera de las señales (por ejemplo, matar -SIGUSR1 pid), luego la lectura fallaría y regresaría.
Su lectura() de 10 GB solo regresará con EINTR si se interrumpió antes de poder leer incluso un solo byte; de lo contrario, devolverá la cantidad de datos que ya había leído (lectura corta = éxito, errno no relevante).
[this was not explained in the linked dupe]
Entonces, si mi comprensión es correcta, ¿qué / por qué debería preocuparme por la llamada al sistema interrumpida ahora …? Parece que el sistema/SO lo maneja automáticamente.
Porque es posible que desee hacer algo al recibir una señal, y no puede hacer mucho desde un controlador de señal; cualquier cosa que use malloc() o stdio (incluso printf()) está fuera de discusión. Por lo tanto, debe manejar las interrupciones en el ciclo principal del programa, y para poder hacerlo, debe romper de alguna manera con una lectura de bloqueo () (una lectura () puede bloquear incluso después de que una encuesta () haya devuelto un fd como listo para leer).
[this was also explained in the linked dupe]