Push signal traps and at_exit blocks to a common thread for exec.

[headius]

This avoids races due to the signal traps running on the JVM's
signal-handling thread while we run at_exit blocks on JRuby's
main thread.

Fixes #5437.

[headius]

@Adithya-copart Can you provide an example script that causes a race and verify that this PR fixes it?

[Adithya-copart]

@headius Will the code in the first comment of puma/puma#1675 work?

## Gemfile


ruby '2.5.0', engine: 'jruby', engine_version: '9.2.0.0'

gem 'sinatra'
gem 'sucker_punch'
gem 'puma'


## config.ru

require 'sinatra/base'
require 'sucker_punch'
require './test_app.rb'

run TestApp

## test_app.rb

class TestApp < Sinatra::Base

  class TestJob
    include SuckerPunch::Job

    def perform
      puts "The job #{self} is starting to sleep 5sec in #{Thread.current}"
      hsh = Thread.list.reduce({}) {|hsh,t| hsh[t] = t.status; hsh}
      # puts "Thread list in #{Thread.current}: #{hsh}"
      sleep 5
      puts "The job #{self} woke up from sleep in #{Thread.current}"
    end
  end

  get '/' do
    3.times {TestJob.perform_async}
  end

end

Steps:
bundle exec puma and hit the URL get '/' and Ctrl + C.
The process should exit if the fix works otherwise it just hangs there.

There is a race between the at_exit in sucker_punch and the trap in puma.

I can recreate something later today if it doesn't.

Thanks!

EDIT: Added the code.

[headius]

@Adithya-copart Ah yes, that's quite similar to how this PR works, except that we use a JDK "ExecutorService" that manages the native thread and queueing for us.

I will try to reproduce based on your instructions.

There are failures in CI, unfortunately. It seems that at least the CRuby/MRI tests expect at_exit to run on the main thread, affecting the main thread's state, raising new exceptions in the main thread, and so on. And as it turns out, CRuby avoids the races you describe by running the signal handlers on the main thread as well. That's right, it hijacks the main thread to run signal handlers.

$ rvm ruby-2.5 do ruby -e 'Signal.trap("INT") { p Thread.current }; p Thread.current; sleep'
#<Thread:0x00007fafdb87dc40 run>
^C#<Thread:0x00007fafdb87dc40 run>

I'm not sure we want to emulate that behavior.

I have a thought for a modification to my fix that just waits for all scheduled signal handlers to execute before proceeding on to the at_exit blocks. We'll see if that helps CI.

[kares]

heh :) ... is this an arbitrary 1h?

[headius]

I thought about it for at least 30 seconds. But yeah it's pretty much arbitrary.

[headius]

This had to be reverted due to some unexpected behavior changes in at_exit. See #5437 (comment).