Debugging now.

@flavorjones: It seems that windows-latest, packaged does release the GVL with busy_timeout 😳:

["busy_handler_timeout", [".", ".", ".", ".", ".", ".", ".", ".", ".", ">", ".", ".", ".", ".", ".", ".", ".", ".", "."]]
["busy_timeout", [".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ">", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", ".", "."]]

Do you see something wrong in the tests, or is Windows just behaving differently with threads?

maybe @tenderlove has time to take a look?

You know what, why do we need a test that the busy_timeout holds the GVL? That isn't actually necessary. The test that busy_handler_timeout allows the work thread to work while retrying is the test that is necessary. I'm just going to delete the other test.

@flavorjones: Removing that test, as fully expected, brings us to green. I see you just reverted, so I will need to add back the actual method, but that is easy enough. If you agree that the one test about busy_timeout is actually superfluous, I will add the method back, keep the new test, and we can move forward with that. Let me know and I will do this tomorrow (headed to bed now)

@flavorjones @tenderlove This adds the code back with a single robust test that asserts the new code behaves how we want. Should be good to go

@flavorjones @tenderlove: Is there anything I need to do to get this reviewed? Not trying to be pushy, only proactive. If you simply are busy in the short-term and can't review PRs in this repo, I understand. I'm only pinging because I know as a maintainer on a level probably with 10x or 100x fewer notifications, it is easy to "mark something as read" and then it slips into the ever-flowing stream of notifications and things to consider.

@fractaledmind no worries, thanks for pinging. CI is green and the patch seems good, so I'll merge!