After my system call has returned because it was interrupted by a signal, is there a way to determine exactly which signal type (i.e. child process termination) caused the interruption?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
After my system call has returned because it was interrupted by a signal, is there a way to determine exactly which signal type (i.e. child process termination) caused the interruption?
There’s a number of facilities in Linux to deal with signals:
waitpid(2)could be used to wait inline forSIGCHLDsigaction(2)could be used to setup handler functions to react to specific signals, theSA_RESTARTflag here affects whether certain system calls are interrupted or restartedsigprocmask(2)could be used to block a number of signalssigwait(3)could be used to wait for number of signals inlinesignalfd(2), which is convenient when one needs to combine signal handling and non-blocking IO.Then there’s the whole next level of complexity when we start talking about threads, though if you deal with signals explicitly you usually don’t really care which signal interrupted the system call.