Avoid port conflict in TCP/IP mode in processes that fork

[crystianwendel]

Problem

When using rdbg with the --port option, I encounter an issue when the process forks, leading to the error:

Address already in use - bind(2) for IP:PORT (Errno::EADDRINUSE)

In my case, I'm using solid_queue, which in its basic configuration starts a Supervisor, Worker, and Dispatcher. This results in multiple processes, and since they all attempt to bind to the same specified port, a conflict occurs.

Feature Request

Change port option in rdbg so it allows specifying a range or list of ports. This would enable the debugger to iterate over the provided range, trying the next available port if one is already in use.

Proposed Solution

Allow rdbg to accept a port range or a list of ports, which it could iterate through to find an open one. For example:

rdbg --port 3003-3005 -n --open -c "./bin/jobs"

In this case, the UI_TcpServer class would attempt to bind to port 3003 first, and if that port is unavailable, it would continue trying 3004, 3005, and so on until it finds an open port.

This would greatly improve the usability of rdbg in environments where multiple processes may be spawned and need to communicate with the debugger.

Additional Context

This issue is particularly relevant in systems with forking processes, such as job queues (e.g., solid_queue), where multiple components (e.g., Supervisor, Worker, Dispatcher) are started. The ability to define a port range would help avoid conflicts and make debugging smoother.

f this enhancement is of interest to the maintainers, I would be happy to contribute by implementing it. Please let me know if this would be a welcome addition.

Thank you for considering this enhancement!

[crystianwendel]

I found that the order in which solid_queue starts its processes is non-deterministic, so relying on a range of ports may not be a reliable solution. I wouldn't be able to predict which port my worker process would be running on.

An alternative approach could be to introduce a REGEX parameter, which would allow the TCP/IP connection to only start when the process information matches the given pattern. This way, the debugger could attach to the correct process based on more specific criteria, potentially avoiding the port conflict issue altogether.

[gerymate]

Hopefully this PR would solve that.