Better byebug integration

[nateberkopec]

Cluster-mode Puma and byebug (default gem in Rails) play poorly together.

Not sure what a good course of action is here.

[nateberkopec]

Unfortunately, I imagine debuggers hold the GVL while they're open, so I'm not sure we can do much.

Maybe we just need to open a PR to Rails to increase worker_timeout (or disable?) in dev.

[nateberkopec]

I wonder if we could detect whether or not a debugger session has begun.

[nateberkopec]

Other options here:

1. If we go into a debugger session, send something on the pipe that says "stop checking me, I'll be back later" and don't ever terminate that worker
2. Find a way to make the worker checkin pass even during a debugger session

[cjlarose]

I'm not sure the linked SO post is related. I use pry and pry-remote regularly on Rails apps running under cluster-mode puma that I help maintain and I don't encounter timeouts (worker_timeout is the default value of 60 seconds). I think pry only hijacks the currently-executing thread, so it doesn't affect the worker's check-in/heartbeat thread. I'm not sure what problem the OP in the SO post was encountering, but I don't think their experience is typical.

That said, I think byebug is different in that it'll pause the execution of all Ruby threads of the process, so I think the title of the issue might still be correct. Have you seen reports of byebug specifically causing a problem for people? There might be a better issue to link instead.

[nateberkopec]

Just took another look here. I'm 95% sure this is because byebug is using a c-ext to do what it does, and that c-ext does not unlock the GVL.

C-extensions hold the GVL unless explicitly unlocked, and other threads will not pre-empt a thread inside a C-extension, holding the GVL.

This is why you can't repro the issue with pry, because pry is written completely in Ruby.

I believe rails/rails#40503 is the best workaround for this issue.