Session mode

This is further to the discussions in #meta and the 2019 Hacktoberfest channel, and https://github.com/python-discord/site/issues/210

It would be excellent if Snekbox supported a kind of “session mode”. Such a mode would allow one to run a persistent Python process in order to serve up a Python REPL or other long-running interactive application. There are some hang-ups to this approach, however…

Shared Processes

Having Python processes that are shared between multiple sessions is probably not possible for a code-based REPL, as it’s pretty easy to escape the code session and mess with the process or other sessions running in the process.

This means that running a process per-REPL with some kind of time limit or max process limit or something is probably the best approach, but this could get heavy on resources if we’re not careful

lemon suggested looking at PEP 0554 on Discord, which could be very useful for an eventual implementation when it comes to shared processes.

Worker Routing

The current design of Snekbox makes routing to specific workers impossible, and they don’t have a mechanism of communicating with each other in order to route to the correct Python process. Additionally, Gunicorn does not have any way to route requests to specific workers - it’s a fundamental part of how Gunicorn works that prevents us from doing this.

That said, there are a few approaches I think we could take.

1. A separate daemon could be run that supports asynchronous access and dispatches to persistent processes running under nsjail as required
2. Falcon could be dropped and replaced with something that is designed with asynchronous programming in mind and is intended to be run as a single worker
3. REPL scope could be serialised and stored in the database somehow, and reloaded on each request - but this could make operations very slow indeed

---

I’m entirely unsure what the best approach to this would be, however. The nature of webapps means that you usually distribute load between workers in order to keep things fast, but doing that means you lose a way to route to the same worker for any set of requests.

Does anyone have any comments on this?

[lemonsaurus]

good write-up. I’ll get in touch with them.

[MarkKoz]

This hasn’t gone anywhere, and I don’t feel it’s the direction the eval feature on the bot, let alone snekbox, should go in anyway.