Hi! On 21:12 Fri 23 Jan , Shyam Burkule wrote: ... > 2) When a system call is slow and a signal arrives while it was > blocked, waiting for something, the call is aborted and returns -EINTR, so > that the library function will return -1 and set errorno to EINTR.Just > before the system call returns, the user program's signal handler is called. > > > In second case, I am not understanding that why not system call execution is > restarted by default, once handler get executed? I know that can be > automated by installing the signal handler using a call to sigaction with > the SA_RESTART flag set, but why not it is default? This is something glibc does. See http://www.gnu.org/software/libc/manual/html_mono/libc.html#Interrupted-Primitives ========== A signal can arrive and be handled while an I/O primitive such as open or read is waiting for an I/O device. If the signal handler returns, the system faces the question: what should happen next? POSIX specifies one approach: make the primitive fail right away. The error code for this kind of failure is EINTR. This is flexible, but usually inconvenient. Typically, POSIX applications that use signal handlers must check for EINTR after each library function that can return it, in order to try the call again. Often programmers forget to check, which is a common source of error. The GNU library provides a convenient way to retry a call after a temporary failure, with the macro TEMP_FAILURE_RETRY: - Macro: TEMP_FAILURE_RETRY (expression) This macro evaluates expression once, and examines its value as type long int. If the value equals -1, that indicates a failure and errno should be set to show what kind of failure. If it fails and reports error code EINTR, TEMP_FAILURE_RETRY evaluates it again, and over and over until the result is not a temporary failure. The value returned by TEMP_FAILURE_RETRY is whatever value expression produced. BSD avoids EINTR entirely and provides a more convenient approach: to restart the interrupted primitive, instead of making it fail. If you choose this approach, you need not be concerned with EINTR. You can choose either approach with the GNU library. If you use sigaction to establish a signal handler, you can specify how that handler should behave. If you specify the SA_RESTART flag, return from that handler will resume a primitive; otherwise, return from that handler will cause EINTR. See Flags for Sigaction. Another way to specify the choice is with the siginterrupt function. See BSD Handler. When you don't specify with sigaction or siginterrupt what a particular handler should do, it uses a default choice. The default choice in the GNU library depends on the feature test macros you have defined. If you define _BSD_SOURCE or _GNU_SOURCE before calling signal, the default is to resume primitives; otherwise, the default is to make them fail with EINTR. (The library contains alternate versions of the signal function, and the feature test macros determine which one you really call.) See Feature Test Macros. ========== It is defined by posix. Changing it may break existing applications. -Michi -- programing a layer 3+4 network protocol for mesh networks see http://michaelblizek.twilightparadox.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
