As with implementing signal handlers in C or most other languages, all code passed to
Signal.trap must be reentrant. If you are not familiar with reentrancy, you need to read up on it at Wikipedia or elsewhere before reading the rest of this document.
Most importantly, “thread-safety” does not guarantee reentrancy; and methods such as Mutex#lock and Mutex#synchronize which are commonly used for thread-safety even prevent reentrancy.
The Ruby VM defers
Signal.trap callbacks from running until it is safe for its internal data structures, but it does not know when it is safe for data structures in YOUR code. Ruby implements deferred signal handling by registering short C functions with only async-signal-safe functions as signal handlers. These short C functions only do enough tell the VM to run callbacks registered via
Signal.trap later in the main Ruby
When in doubt, consider anything not listed as safe below as being unsafe.
Mutex#lock, Mutex#synchronize and any code using them are explicitly unsafe. This includes
Monitor in the standard library which uses Mutex to provide reentrancy.
Dir.chdir with block
IO write operations when
IO#sync is false; including
IO#puts. Pipes and sockets default to `IO#sync = true', so it is safe to write to them unless
IO#sync was disabled.
File#flock, as the underlying flock(2) call is not specified by POSIX
Assignment and retrieval of local, instance, and class variables
Additionally, signal handlers do not run between two successive local variable accesses, so shortcuts such as `+=' and `-=' will not trigger a data race when used on
Float classes in signal handlers.
Dir.chdir (without block arg)