Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for rr.spawn(serve=True) for multiprocess web-viewing #7768

Open
teh-cmc opened this issue Oct 16, 2024 · 2 comments
Open

Support for rr.spawn(serve=True) for multiprocess web-viewing #7768

teh-cmc opened this issue Oct 16, 2024 · 2 comments
Labels
enhancement New feature or request 🪵 Log & send APIs Affects the user-facing API for all languages user-request This is a pressing issue for one of our users

Comments

@teh-cmc
Copy link
Member

teh-cmc commented Oct 16, 2024

Users want to be able to log to the web-viewer from multiple processes, just like they do with the native viewer.

This requires an intermediate proxy, so all the data can go through a single websocket port, which the web-viewer then knows to poll.
The solution today is to manually start a tcp+websocket server with rerun --serve, then just use rr.connect() in all your clients.

That manual step is annoying, and AFAICT, could be automated away by augmenting rr.spawn().

All rr.spawn() does is basically fork_exec("rerun --port={port}"). We could add an extra serve: bool parameter, and then rr.spawn(serve=True) would bottom out in fork_exec("rerun --port={port} --serve").
Assuming our usual policy of "silently re-use the existing instance in case of conflicted ports", that means every client could just call rr.spawn(serve=True) and voila, all the processes are logging to the same web-viewer.

Related:

@teh-cmc teh-cmc added enhancement New feature or request user-request This is a pressing issue for one of our users 🪵 Log & send APIs Affects the user-facing API for all languages labels Oct 16, 2024
@teh-cmc
Copy link
Member Author

teh-cmc commented Oct 24, 2024

And now that I'm documenting the application model (#919), I'm realizing that doing this would provide a level of consistency that would allow me to concisely state:

rr.spawn(serve=False) = rerun &
rr.spawn(serve=True)  = rerun --serve &

and that would be very nice.

@emilk
Copy link
Member

emilk commented Nov 4, 2024

Ideally spawn should have all the flags that the binary has

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request 🪵 Log & send APIs Affects the user-facing API for all languages user-request This is a pressing issue for one of our users
Projects
None yet
Development

No branches or pull requests

2 participants