Feature #7918: Create Signal.in_trap?()

• Status: Rejected
• Assignee: kosaki (Motohiro KOSAKI)
• Target version: 2.2.0

[kosaki (Motohiro KOSAKI)]

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?

[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

[ko1 (Koichi Sasada)]

(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 at atdot dot net

[normalperson (Eric Wong)]

SASADA Koichi [e-mail] 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?

[kosaki (Motohiro KOSAKI)]

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

false.

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

[kosaki (Motohiro KOSAKI)]

On Sun, Feb 24, 2013 at 1:15 PM, SASADA Koichi [e-mail] 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.

[kosaki (Motohiro KOSAKI)]

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.

[kosaki (Motohiro KOSAKI)]

• Status changed from Open to Assigned
• Assignee set to kosaki (Motohiro KOSAKI)

[hsbt (Hiroshi SHIBATA)]

• Target version changed from 2.1.0 to 2.2.0

[akr (Akira Tanaka)]

• Status changed from Assigned to Rejected

Queue is a better solution now.
So we reject this issue.