Providing independent sandboxed evaluation for every visitor to the site costs a lot of memory. On my Linode 512, it only takes about 90 users before all the memory is consumed and I have to start garbage collecting. If you saw that message when you tried to evaluate something, you probably got GC'd.
I'd like to find a more graceful way of handling this. Any suggestions?
I'm not familiar with Arc's internals or the effect that this would have in the context of GC, but as a hack, perhaps you could assign multiple people to a single interpreter instance, prepend prefixes to symbols to avoid collisions before evaluating (e.g. user_1_total, user_1_total, user_2_total), and make each user optionally aware of commands from other users on that instance (e.g. implemented as in-browser chat), letting individual evaluations block each other -- I doubt anyone's doing anything particularly heavy-duty or time-sensitive on your server.
This is convoluted and fragile, but if I wanted to roll out "sandboxes" on limited hardware I'd start with something like this.
This is a very clever idea. Even if I don't implement it this way, your suggestion has inspired me to think outside the box.
Here's an approach that's a variation/refinement of my current one: Instead of just orphaning old clients when their sandboxes get GC'd, leave them with a local copy of their REPL history. If they try to use the REPL again after a long period of silence, a new sandbox will be allocated for them (as it would be for a fresh client), and all the commands in their REPL history loaded in to bring it back to its previous state.
This approach could potentially pave the way for users having persistent REPLs, even across page reloads.
I'd like to find a more graceful way of handling this. Any suggestions?