Feature #7918

Create Signal.in_trap?()

Added by Motohiro KOSAKI about 1 year ago. Updated 2 months ago.

[ruby-core:52727]
Status:Rejected
Priority:Normal
Assignee:Motohiro KOSAKI
Category:core
Target version:current: 2.2.0

Description

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?

History

#1 Updated by Tomoyuki Chikanaga about 1 year ago

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.intrap?(:USR2) # => true
p Process.in
trap?(:USR1) # => true or false?
end
Process.kill(:USR1, $$)
sleep

#2 Updated by Koichi Sasada about 1 year ago

(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

#3 Updated by Eric Wong about 1 year ago

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?

#4 Updated by Motohiro KOSAKI about 1 year ago

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.intrap?(: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.

#5 Updated by Motohiro KOSAKI about 1 year ago

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.

#6 Updated by Motohiro KOSAKI about 1 year ago

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.

#7 Updated by Motohiro KOSAKI 8 months ago

  • Status changed from Open to Assigned
  • Assignee set to Motohiro KOSAKI

#8 Updated by Hiroshi SHIBATA 3 months ago

  • Target version changed from 2.1.0 to current: 2.2.0

#9 Updated by Akira Tanaka 2 months ago

  • Status changed from Assigned to Rejected

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

Also available in: Atom PDF