Issue #14222 has been updated by Eregon (Benoit Daloze).

Assignee changed from ruby-core to normalperson (Eric Wong)

normalperson (Eric Wong) wrote:
>  > 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.

I think that would be very helpful and help to discuss possible improvements.
Also explaining why Mutex is problematic (the signal handler can be run between any 2 lines of code, and Mutex is not re-entrant).
Can I assign this to you to create the document?

----------------------------------------
Misc #14222: Mutex.lock is not safe inside signal handler: what is?
https://bugs.ruby-lang.org/issues/14222#change-69820

* Author: hkmaly (Honza Maly)
* Status: Open
* Priority: Normal
* Assignee: normalperson (Eric Wong)
----------------------------------------
As mentioned in #7917, Mutex.lock is not safe inside signal handler. As mentioned in #6416, neither is Thread.join. But there seem to be no documentation about what IS safe to do inside signal handler. In C, it is not safe to just modify variable inside signal handler without locking. Is it safe in ruby in case of 1) global variable 2) class variable 3) object variable 4) thread local variable, as in Thread.current['local_var'] ? Is there any other method of locking usable inside trap content?

Note that while response in this issue would be useful it would be even better if it appeared in official ruby documentation, if there is any. I realize it is not directly bug but it's likely going to be cause of many bugs if the answer is "no" on any part of this and only people who understand ruby core can answer this.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>