3

I'm trying to find resources talking about handling synchronous signals (SIGSEGV, SIGILL etc.) compared to handling async signals.

The typical signal handling mechanism (using kill, for example) invokes signal handlers on control transfer from kernel to user mode. My understanding is that a 'synchronous' signal works more like a system call in that control transfers to kernel immediately - probably because synchronous signals are typically associated with CPU interrupts (memory protection etc.) and the kernel handler gets invoked for these anyway.

  1. Are libc functions which are otherwise 'async-signal-unsafe' safe to be used in synchronous signal handlers? I see the Linux mprotect(2) man page uses printf inside a SIGSEGV handler, for example. How can I determine if a function can be used in these situations?

  2. How does a typical Unix-like kernel's handling of synchronous signals differ from its handling of async signals? What makes them 'synchronous'?

Shrikant Giridhar
  • 379
  • 4
  • 14

4 Answers4

7

There are no synchronous and asynchronous signals by nature, but some signals are delivered asynchronously and some other can be delivered sync or async.

Delivery is always the same: a signal handler in user mode is called if set. If not set then a default behavior is used (default behavior is terminating the process, except for some signals for which ignoring or pausing is done).

Signals are considered to be delivered asynchronously if they are initiated by some external cause (for example somebody else called kill). In such a case from the point of view of the process there is time in between emitting and delivering: process can execute many things...

Signals are delivered synchronously if some internal runtime cause is detected for which a signal should be emitted. For example, a bad memory access which can deliver SIGSEGV or SIGBUS, a floating point error like division by zero which deliver SIGFPE, a bad instruction (SIGILL), etc. In such a case it is the current executed code/instruction that is the source of the fault, then signal is immediately emitted and then delivered. In this case from the point of view of the process nothing happens in between emitting and delivery.

Jean-Baptiste Yunès
  • 34,548
  • 4
  • 48
  • 69
  • How does synchronous vs. asynchronous delivery affect the async-signal-safety of the program? Consider the program in `man mprotect(2)` on Linux. Is the handler incorrect in using a async-signal-unsafe function? – Shrikant Giridhar Sep 06 '17 at 00:57
  • Yes it is not correct to use async-signal-unsafe function in **any** signal handler, just because you'll never know if the occurence of the signal is synchronous or not. (1) some external event may produce a SIGFPE (for example), so your process is unable to know if it is synchronous or not (2) you never know if in occurence of synchronous delivery the call to async-unsafe function is permitted. So **don't call async-signal-function in signal handlers**. – Jean-Baptiste Yunès Sep 06 '17 at 06:42
0

I think that one of the best resources out there are the:

Capybara
  • 1,313
  • 8
  • 12
0

There are two parts here. The generating of signals and the receipt of signals. Signals are received by the program through signals handlers. As far as a signal handler is concerned, the receipt of the signal is always asynchronous (i.e. it cannot predict when it will be received).

Whether generating a signal is synchronous or asynchronous is another question. An interrupt from an external device is clearly asynchronous. A call from a program to raise a signal will block that program until the call returns. During the call the signal can be sent asynchronously (i.e. it is placed in a queue for the receiving program) or synchronously (i.e. the signalled program's handler is invoked and the signalling program/thread is suspended until the handler returns, possibly returning some value.) An example of this is the Windows SendMessage (synchronous) and PostMessage (asynchronous)

Addition: "An interrupt from an external device is clearly asynchronous" and suspends the currently running process untill the handler has finished. So a segmentation violation, a hardware interrupt, suspends the currently running process (which generated the hardware signal). Its default handling will be to terminate the process.

Paul Ogilvie
  • 25,048
  • 4
  • 23
  • 41
  • If the current process is suspended on a SIGSEGV, for example, would it be safe to execute othewise unsafe functions i.e. `printf`? Wouldn't the current process still hold locks (for example) even if gets suspended? – Shrikant Giridhar Sep 06 '17 at 02:36
  • No call to printf is not permitted (at least the behavior is undefined). Signal delivery does nothing on global state of process, except some things about signal management (signal mask, etc). So locked locks, remains locked... – Jean-Baptiste Yunès Sep 06 '17 at 06:45
0

Signal handling As mentioned previous comment are synchronous and asynchronous. Synchronous means process/thread wile executing some instruction and this execution have caused the interrupt. forex int *a;printf("%d",*a);can cause segmentation fault. Asynchronous:-client process and server process example:-server is going down it will send signal to client to stop.Here client is not generating any interrupt it is from externally process. Whenever there is synchronous interrupt that means something wrong with the process.Suggested is to keep handling as minimum as possible no library or complex statement.Suppose interrupt is due to malloc failure than if some library function is used again this will again cause problem.Better way is to do a automatic process restart in signal handler itself.

Rohit
  • 142
  • 8