[ruby-core:84526] Re: [Ruby trunk Misc#14222] Mutex.lock is not safe inside signal handler: what is?

[e-mail] 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: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>