-2

In Linux, many signals are generated when some associated events occur.

  • How are the associations between signals and events created, removed, modified, enabled and disabled? (preferably in terms of API)

  • There are signals used by the kernel, and signals that are user defined, and are they treated differently?

Tim
  • 101,790

1 Answers1

2

Both “reliable” and “real-time” signal generation, delivery, and default handling are specified by POSIX. This specification defines which events generate which signals. Linux adds a few signals corresponding to traditional signals from other Unix systems. If you want to add, remove, or modify an association between an event and a signal, you’d have to get it implemented in an operating system, and then make your case to the Austin Group (where POSIX is written).

The APIs available to control signal generation, delivery, and handling are extensive, see the links above for details. Some of these control how signals are handled (default action, ignored, or specific handler), but the association between an event and a signal itself can’t be controlled. Thus a floating-point exception will always result in SIGFPE, which may be handled in different ways; a process can issue SIGFPE manually in other circumstances too, but the connection between a floating-point exception and SIGFPE can’t be disabled.

Some reliable signals are designed for user-defined purposes, SIGUSR1 and SIGUSR2. There is no pre-established event corresponding to these signals, but there is a pre-established action (which terminates the receiving process). It is up to the generating process to determine which events result in one of these signals being generated; there is no way to tell the kernel to automatically generate such a signal in certain circumstances. (BPF programs can send signals, so signal-generating code can be hosted in the kernel, but that’s not quite the same.)

Real-time signals are all user-defined. As with user-defined reliable signals, they terminate the receiving process by default.

Your second question is already addressed in What causes various signals to be sent?

Stephen Kitt
  • 434,908
  • Thanks. But doesn't answer my questions of whether the associations between signals and events can be created, changed, removed, disabled and enabled. At least not directly answer them. – Tim Dec 10 '20 at 11:41
  • There are a few signals left for users to define. How are their associations with events created, removed, changed, enabled and disabled? – Tim Dec 10 '20 at 12:06
  • They’re user-defined, so what they do and why they do it is up to the user (although reliable signals have default handlers which usually terminate the caller). I don’t understand what you’re after — do you want to know how to set up a signal handler and how to generate a signal? – Stephen Kitt Dec 10 '20 at 13:51
  • How to give meanings (i.e. associated events) to user defined signals, i.e. how to define when user defined signals are generated. Whether generation of system defined signals can be enabled or disabled, and whether their associated events can be changed. – Tim Dec 10 '20 at 14:32
  • "It is up to the generating process to determine which events result in one of these signals being generated". Do you mean SIGUSR1 and SIGUSR2 and Real-time signals are generated only explicitly by system calls kill(), raise(), not implicitly? – Tim Dec 11 '20 at 11:29
  • "This specification defines which events generate which signals. Linux adds a few signals corresponding to traditional signals from other Unix systems. If you want to add, remove, or modify an association between an event and a signal, you’d have to get it implemented in an operating system, and then make your case to the Austin Group (where POSIX is written)". How about disabling and enabling? – Tim Dec 11 '20 at 11:31
  • Yes, user-defined signals are only generated by explicit calls. Re disabling and enabling associations between events and signals, “the association between an event and a signal itself can’t be controlled”. – Stephen Kitt Dec 11 '20 at 11:48
  • In place of disabling and enabling associations between events and signals at signal generation, set their disposition for a process to be SIG_IGN? – Tim Dec 11 '20 at 12:03
  • The disposition affects handling, not the association; that’s why I distinguished the two in the answer. “The APIs available to control signal generation, delivery, and handling are extensive, see the links above for details. Some of these control how signals are handled (default action, ignored, or specific handler)” – Stephen Kitt Dec 11 '20 at 12:17