You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Summary:
Pull Request resolved: meta-pytorch#800
This change introduces a new kind of identifier used to parse direct procs.
As we plan to phase out ranked procs, this will become the only kind of identifier in the system.
```
# The proc "proc-name" at tcp:[::1]:1234
tcp:[::1]:1234,proc-name
# The root actor "actor-name" at the above proc
tcp:[::1]:1234,proc-name,actor-name
# ... equivalent to:
tcp:[::1]:1234,proc-name,actor-name[0]
# A child actor of the above actor:
tcp:[::1]:1234,proc-name,actor-name[123]
```
## Alternatives considered
The central challenge with this syntax is satisfying the following simultaneously:
1) Unambiguous parsing: all while mixing channel addresses and procs, actor names, and PIDs
2) A shell-friendly syntax: we do not want to have to impose quoting or escaping in typical cases
3) Make it simple, drawing on only a few lexemes
For example, the first requirement precludes a straightforward URL syntax, consider:
```
tcp://[::1]:1234/proc-name/actor-name/pid
```
but what happens when you introduce unix sockets?
```
unix:///path/to/socket/proc-name/actor-name/pid
```
How do you delimit the socket address from the proc name?
One alternative is to introduce another delimiter, e.g.:
```
unix:///path/to/socket//proc-name/actor-name/pid
```
but now this looks rather like line noise! And it's hard to parse!
One alternative I liked is to quote the channel address: this sets it apart, and signifies a separate syntax.
```
"tcp:[::1]:1234".proc-name.actor-name[pid]
```
but the shell parses the quotes!
Similar issues exist for other alternatives, which can be parsed unambiguously, but would make the grammar more complicated:
```
# Brackets compete with IPv6 addresses, requiring recursive descent parsing
unix[/foo/bar].proc-name.actor-name[pid]
# "::" clash with IPv6 addresses, requiring additional context to parse correctly
unix:/foo/bar::proc-name::actor-name[pid]
```
And so on.
All of this being said: if you find a clearly superior alternative, I am all ears.
ghstack-source-id: 301740077
exported-using-ghexport
Reviewed By: shayne-fletcher
Differential Revision: D79856404
fbshipit-source-id: 60b479091af52c3f15f2c6bf446639fab05f60ee
0 commit comments