From: Eric Wong Date: 2017-12-27T19:58:55+00:00 Subject: [ruby-core:84526] Re: [Ruby trunk Misc#14222] Mutex.lock is not safe inside signal handler: what is? eregontp@gmail.com wrote: > Could MRI simply use the self-pipe trick or similar internally, and execute signal handlers on the main thread by using Ruby's interrupts? (RUBY_VM_CHECK_INTS) > A bit like Thread#raise except it would execute the signal handler instead of throwing an exception. > That would allow to run any kind of code in signal handlers. > The timer thread could listen for signals and interrupt the main thread to execute the handler, since that code is likely not async-signal safe. We already do this. If we didn't, hardly any Ruby code would be safe inside a signal handler, not even creating a string. > Of course, it doesn't solve the problem of calling SOME_LOCK.lock in the handler if SOME_LOCK is already locked by the main Thread. Exactly! > But that seems rarely a problem, and internal locks could be reentrant (e.g. IO locks). One could say most bugs are rarely a problem... but there is no place for optimism when the goal is robust software ;) Reentrant locks aren't cheap, either; so I don't think they're good for something as common as IO operations. Not to mention they are tricky and probably lead to bad design (require/autoload uses them, and yes, it's tricky and we've had problems there). > Having a not-well defined set of allowed operations in a Ruby block (the signal handler) seems a much larger problem worth fixing. Maybe we can list out safe methods for signal handlers somewhere. Maybe create doc/signals.rdoc? signal(7) in Linux manpages has a similar list. I can help review/maintain it. Unsubscribe: