`Signal#trap` should return previous handler

[straight-shoota]

When you trap a signal, you replace any previous definition with your own, overriding any default behavior.

This is an additional problem.

In Ruby-land Signal.trap returns the previous handler,
so you can safely chain them.

Crystal currently has no equivalent to this.

This is problematic when for example a shard needs
to add a signal-handler. As of today it has no way to
preserve (or even detect) an already attached handler.

I'd like to propose the following syntax to enable signal handler chaining:

Signal::INT.trap do
  puts "Trap 1"
  exit
end

Signal::INT.trap do |previous_handler|
  puts "Trap 2"
  previous_handler.call
end

Output on signal:

Trap 2
Trap 1

Originally posted by @m-o-e in #8687 (comment)

[stakach]

I think being able to check for any previously defined handler would be a good addition and otherwise leave the current behaviour as is.

existing_callback = Signal::HUP.trap_handler?

I don't think we need much more than this as really libraries shouldn't be handling signals (code smell to me, just as libraries shouldn't be calling exit etc), it should just be the final application that deals with signals

So this provides a work around for any situation that does arise where chaining is required

[m-o-e]

I'm not married to any particular syntax - so I'm fine with either.

libraries shouldn't be handling signals

There are libraries that need to, e.g. CLI related ones.
(e.g. a library providing a readline()-method wouldn't be very useful if it doesn't handle SIGINT)

[straight-shoota]

This might be slightly off-topic, but maybe not...?

(e.g. a library providing a readline()-method wouldn't be very useful if it doesn't handle SIGINT)

Actually, readline implementations typically set a TTY into raw mode thus reading the key inputs directly. That means the terminal doesn't intercept Ctrl+C. It does not send SIGNIT and thus there's no reason to handle it.

Perhaps there are other use cases in libraries. But I don't think there would be many.
Maybe a library that completely takes care of the CLI handling. But then it would handle everything and there's no need for other code to integrate with the library.

[m-o-e]

readline implementations typically set a TTY into raw mode thus reading the key inputs directly

Valid point, I chose a bad example indeed.

But still. Even if we agree that handling signals in a
shard should never be necessary - people do it anyway.

So, in the immortal words of Larry Wall:

When they first built the University of California at Irvine they just put the buildings in.
They did not put any sidewalks, they just planted grass. The next year, they came back
and put the sidewalks where the trails were in the grass.

[stakach]

I totally agree that people will do it and being able to work around it is desirable.
So I think we all agree on a reasonable way forward?

Do you think trap_handler? is a good method name for checking for the existence / returning the previous version of a callback @straight-shoota

I've added this method to the pull request #13694

[straight-shoota]

That looks good to me 👍
It's really an indepentend feature though, so we should extract it into a separate PR.