Byebug.start_server: yield later, when actual_port is known #277
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I didn't find docs or tests for
start_server
taking a block;not sure how you intended that to be used and whether you'll consider this backward-compatible.
This allows
wait_connection=true
to be meaningfully used withport=0
.(If it doesn't return until a client connects,
but a client can't know what port it will listen on,
then here is the only chance to tell the client what port to use.)
My (ab)use case is debugging an app with many background workers.
I wanted to use remote byebug, but I'd have to make each worker listen on a different port, and connect to them all. (To make things worse, workers are sometimes created/destroyed.)
Instead I wrote this kludge: https://gist.github.com/cben/4d4851f63ded79b74d1cb162422ff13b
which at the breakpoint starts a server and a new terminal with a client that connects to it.
I wanted to avoid manually specified ports with retries on collisions; port=0 is perfect.
But I also wanted wait_connection, which is hard to fake externally as the mutex is not exposed...
With this patch that code could be reduced to something like: