Is it possible to have multiple traps for a signal - ruby

Question

I'm trying to understand Ruby's traps for standard signals.
In specific, I'm trying to have multiple signal handlers ("traps") for the same signal. It seems impossible. Here's a super simplified code to demonstrate the problem:
file traps.rb:
should_stop = false
Signal.trap 'INT' do
# won't be executed :(
puts 'int --> A'
should_stop = true
end
Signal.trap 'INT' do
# will be executed
puts 'int --> B'
should_stop = true
end
times = 0
until should_stop
puts 'waiting to stop'
sleep 1
times += 1
break if times >= 5
end
puts 'done'
Run the code:
ruby traps.rb
Output without pressing CTRL+C:
waiting to stop
waiting to stop
waiting to stop
waiting to stop
waiting to stop
done
Output with pressing CTRL+C after 2 seconds:
waiting to stop
waiting to stop
^Cint --> B
done
It seems that only the last signal trap to be declared is the one which would be executed.
Is this behavior by design?
If not, how can we have multiple handlers executed to the same signal?
The main reason for asking this is that third party libraries might add their trap to a signal.
If we have two different third party libraries that add their trap to the same signal, only one of them would actually be executed. That's where the fun begins :(

Answer 1

It seems that only the last signal trap to be declared is the one which would be executed.
Is this behavior by design?
It is not very explicit in the documentation of Signal::trap, but it is by design:
The command or block specifies code to be run when the signal is raised.
Note the use of the singular, and the absence of any mention of something like "The command or block is added to the list of trap handlers to be run when the signal is raised."
It becomes clearer if you look at the POSIX trap shell builtin after which Signal::trap is modeled:
The action of trap shall override a previous action (either default action or one explicitly set).
The POSIX sigaction function which is the C equivalent to trap says more or less the same thing. Note, however, that the sigaction function also gives a way of retrieving the function pointer to the old action, so theoretically, you could set the action to a function pointer to a new action which uses the function pointer to the old action to call the old action as part of itself, thus in some way chaining the actions.
Note, however, that this would require the old and new action cooperate in some way. Also note that this mode of operation is not modeled by POSIX trap.
If not, how can we have multiple handlers executed to the same signal?
From the documentation:
trap returns the previous handler for the given signal.
So, Signal::trap implements the behavior from sigaction that gives you access to the "old" handler. You could save that old handler somewhere and chain the calls by explicitly calling it from your new handler.
Like with sigaction, this requires some form of cooperation between the handlers.

Answer 2

Combining the answer from Jörg W Mittag and the documentation, here's a simplified solution:
# file traps.rb
should_stop = false
Signal.trap('INT') do
puts 'int --> A'
should_stop = true
end
$prev_trap = Signal.trap('INT') do
puts 'int --> B'
should_stop = true
$prev_trap&.call
end
times = 0
until should_stop
puts 'waiting to stop'
sleep 1
times += 1
break if times >= 5
end
puts 'done'
After running ruby traps.rb, and pressing CTRL+C after 3 seconds, the output looks like this:
waiting to stop
waiting to stop
waiting to stop
^Cint --> B
int --> A
done