Forum: Ruby-core [ruby-trunk - Feature #7918][Open] Create Signal.in_trap?()

Issue #7918 has been reported by kosaki (Motohiro KOSAKI).

----------------------------------------
Feature #7918: Create Signal.in_trap?()
https://bugs.ruby-lang.org/issues/7918

Author: kosaki (Motohiro KOSAKI)
Status: Open
Priority: Normal
Assignee:
Category: core
Target version: 2.1.0


Currently, ruby library have no way to detect a method is called from 
trap handler or not.
This is useful because Mutex#lock under trap raises an exception and 
some libraries may want to avoid it.

Then, I would like to create Signal.in_trap?() class method.

Signal.in_trap?(signal = nil)

return true when running trap handler.
return false otherwise.

When signal argument is specified, return true only when running trap of 
specified signal.

Thought?

Issue #7918 has been updated by nagachika (Tomoyuki Chikanaga).


Hello,

This feature looks reasonable for me.

I'd like to clarify the specification. Should the following code show 
true? or false?

Signal.trap(:USR1) do
  Process.kill(:USR2, $$)
end
Signal.trap(:USR2) do
  p Process.in_trap?(:USR2)   # => true
  p Process.in_trap?(:USR1)   # => true or false?
end
Process.kill(:USR1, $$)
sleep

----------------------------------------
Feature #7918: Create Signal.in_trap?()
https://bugs.ruby-lang.org/issues/7918#change-36950

Author: kosaki (Motohiro KOSAKI)
Status: Open
Priority: Normal
Assignee:
Category: core
Target version: 2.1.0


Currently, ruby library have no way to detect a method is called from 
trap handler or not.
This is useful because Mutex#lock under trap raises an exception and 
some libraries may want to avoid it.

Then, I would like to create Signal.in_trap?() class method.

Signal.in_trap?(signal = nil)

return true when running trap handler.
return false otherwise.

When signal argument is specified, return true only when running trap of 
specified signal.

Thought?

(2013/02/23 11:31), kosaki (Motohiro KOSAKI) wrote:
> Currently, ruby library have no way to detect a method is called from trap 
handler or not.
> This is useful because Mutex#lock under trap raises an exception and some 
libraries may want to avoid it.

I'm not sure why it is useful. If a lock is needed, then the lock should
be acquired in trap handler (and not supported yet). Detecting it is in
trap, and do what?

SASADA Koichi <ko1@atdot.net> wrote:
> (2013/02/23 11:31), kosaki (Motohiro KOSAKI) wrote:
> > Currently, ruby library have no way to detect a method is called from trap 
handler or not.
> > This is useful because Mutex#lock under trap raises an exception and some 
libraries may want to avoid it.
>
> I'm not sure why it is useful. If a lock is needed, then the lock should
> be acquired in trap handler (and not supported yet). Detecting it is in
> trap, and do what?

How about allowing Mutex#lock to be recursive if (and only if) called
inside trap?

> sleep
false.

Because trap handler never be nested. I changed it at 2.0 for
preventing stack overflow issue.
No confusion.

On Sun, Feb 24, 2013 at 1:15 PM, SASADA Koichi <ko1@atdot.net> wrote:
> (2013/02/23 11:31), kosaki (Motohiro KOSAKI) wrote:
>> Currently, ruby library have no way to detect a method is called from trap 
handler or not.
>> This is useful because Mutex#lock under trap raises an exception and some 
libraries may want to avoid it.
>
> I'm not sure why it is useful. If a lock is needed, then the lock should
> be acquired in trap handler (and not supported yet). Detecting it is in
> trap, and do what?

The most obvious usecase is to improve better error handling and
better error messages.

And yes, we need several further steps. e.g. masking trap.

>> I'm not sure why it is useful. If a lock is needed, then the lock should
>> be acquired in trap handler (and not supported yet). Detecting it is in
>> trap, and do what?
>
> How about allowing Mutex#lock to be recursive if (and only if) called
> inside trap?

I disagree. Recursive or not recursive depend on protected code and data
structure. Some case is safe and some another case is unsafe for 
recursive.

Then instead, I suggest to make RecursiveMutex class into stdlib. and
making a chance
rubyist choose a right mutex.