Skip to content
This repository has been archived by the owner on Aug 2, 2023. It is now read-only.

pydevd: reconnect listener #1708

Closed
int19h opened this issue Aug 21, 2019 · 2 comments
Closed

pydevd: reconnect listener #1708

int19h opened this issue Aug 21, 2019 · 2 comments
Assignees
Milestone

Comments

@int19h
Copy link
Contributor

int19h commented Aug 21, 2019

It should be possible to start pydevd in the mode whereby it opens a listener socket for incoming DAP connections, regardless of the direction of the first connection that it establishes to the client (i.e. even if it's pydevd -> client, and not client -> pydevd). That listener socket should refuse connections for as long as there is one already active, but should accept new connections otherwise.

To enable this mode, we'll use a custom property in the "initialize" request:

{
  ...
  "command": "initialize",
  "arguments": {
    ...
    "pydevd": {
       "serverHost": ...,   // default "127.0.0.1"
       "serverPort": ...,   // can be 0 to pick an available ephemeral port
    }
  }
}

(we'll use the same top-level property for any other custom pydevd-related initialization bits in the future)

The listener socket is enabled if "serverPort" is specified - to pick some available free port, the other side must pass 0.

pydevd must open the listener socket and invoke listen() on it before sending the "initialize" response. The response should contain information about the host and the port on which the socket is actually listening, as returned by getsockname() (which might be different from inputs in case "0.0.0.0" or :0 are used):

{
  ...
  "command": "initialize",
  "success": true,
  "body": {
    ...
    "pydevd": {
       "processId": ...,    // pid of the child process
       "serverHost": ...,   // actual host
       "serverPort": ...,   // actual port
    }
  }
}
@int19h
Copy link
Contributor Author

int19h commented Aug 22, 2019

It would also be nice to always include "processId" as a property in "initialize" response, even in non-multiproc scenarios. This will make it a little bit easier to handle this all uniformly in the adapter.

@fabioz
Copy link
Contributor

fabioz commented Aug 22, 2019

Note: on hold (waiting for e-mail feedback).

@karthiknadig karthiknadig added this to the Aug 2019.2 milestone Aug 22, 2019
@fabioz fabioz closed this as completed Aug 22, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants