Fix compatibility with Fiber Scheduler.

[ioquatix]

This is a first pass at improving the compatibility with the fiber scheduler and contains two changes:

• Ensure the ThreadClient is actually per-thread and not per-fiber.
• Ensure that waiting for events (blocking) is done in a blocking context, otherwise it will be redirected in the fiber scheduler which is probably not desirable.

It only works on 3.2 but could be made to work on 3.0 and 3.1 if some tests were changed.

Fiber.blocking{...} was introduced in Ruby 3.2. It can be emulated by Fiber.new(blocking: true) {...} but the backtrace is changed. This causes some test failures.

My personal opinion is that we can ignore 3.0 and 3.1 but there is an option to support them with the compatibility wrapper outlined above, if we are willing to change some of the tests that check backtraces.

I cannot see any other obvious issues with the debug code. If there are other places where the debug code is executing blocking operations, we should add more Fiber.blocking{...} to avoid entering the fiber scheduler.

[ioquatix]

@ko1 can you please review and also if you want tests, can you suggest what kind of tests to add? The original issue #486 has a complete example and this PR fixes it. However, as you said, you may not want to pull in async to run that sample.

[louim]

Hello! First, thank you @ioquatix for this patch. We are running ruby 3.1 and encountered the bug mentioned in #486. Since this patch is for ruby 3.2+, I went ahead an applied your suggestion to make it work with Ruby 3.1. Here's the branch, rebased on master and with the patch you mentioned. It fixed our problem 🎉 .

I'd be happy to help get this in the debug gem itself. What would be the way forward to make this happen? @ko1, I'd be happy to help in any way I can to get this merged 🚀 .

[louim]

Seems like I spoke too soon 🙃. @ioquatix using Fiber.new(blocking: true) {yield} does not seem to stop the debugger on ruby 3.1. I can see the debugger output appear, but the code continues. Do we need to wrap it with something else?

[ioquatix]

@louim can you try with Ruby 3.1.3?

There were some bug fixes which I hope were backported, it might be responsible.

[louim]

@ioquatix sorry, I didn’t mention it, but we are in fact using ruby 3.1.3.

[ioquatix]

@louim Can you test with this?

    if ::Fiber.respond_to?(:blocking)
      private def fiber_blocking
        ::Fiber.blocking{yield}
      end
    else
      private def fiber_blocking
        ::Fiber.new(blocking: true){yield}.resume
      end
    end

[ioquatix]

With the latest change, the test failures on < 3.2 are stack trace related, as we can't control the stack when using Fiber.new(blocking: true){yield}.resume. So we should skip those tests?

[ko1]

why do you extend the timeout?
this extension will introduce huge slowdown on some cases.

[ioquatix]

I found the test runner was timing out on GitHub actions even in HEAD.