Pry behaves poorly with multiprocess server

[ersinakinci]

Pry is unable to determine for which process you're typing input if multiple workers are stopped at the same time by pry when running a server with multiple workers (e.g., Puma in cluster mode).

Instead of writing my own description, I will shamelessly copy/paste @gdpelican's excellent description of the problem for byebug, since the exact same thing happens with that utility:

Expected behavior

I'd expect byebug to halt just one process at a time and let others through, although I think behaviours other than this could be acceptable, such routing all user input to the first-process byebug until it's released. Or, if the answer is 'we can't support that' (I noted this happens for binding.pry as well, for example), perhaps a note in the docs about it?

Actual behavior

The pry seems to split user input across processes, leading to things like this:

(byebug) cont
*** NameError Exception: undefined local variable or method `on' for #Class:0x00007fa88010e6d8
It seems to be impossible to predict what input goes to what process, meaning the only way out is to kill the server:

(byebug) ccoonntt
*** NameError Exception: undefined local variable or method `ccnt' for #Class:0x00007fa88010e6d8
Steps to reproduce the problem

Place a byebug anywhere in a rails application
Run a rails server with multiple workers to handle web requests.
(I ran into it running the development version of Discourse, which runs 3 unicorn workers by default.)
Perform an action which will cause the byebug to catch
While byebug is still holding the first process, perform an action which will cause the same (or a second) byebug to catch

[ersinakinci]

@deivid-rodriguez started two PR's to fix the problem for byebug:

deivid-rodriguez/byebug#604
deivid-rodriguez/byebug#615

I'm not familiar enough with the topic to understand them. However, I was wondering whether the second PR, which enables Reline support for Byebug, might be relevant. I noticed that Pry also has a request for Reline support: #2063

[barrettkingram]

I can pretty much reproduce this behavior with this script:

require "readline"

2.times do
  Process.fork do
    while buf = Readline.readline("> ", true)
      p buf
    end
  end
end

Process.waitall

I think the same thing is essentially happening with pry and byebug. When two or more processes are using Readline to collect input, key presses seem to get sent to a random process. I also tried using Reline instead but it didn't help much. Not sure what options are available for improving the situation.

[kyrylo]

This is probably a duplicate of #1275.