Hacker News Reader

Comment by bhiggins | Hacker News Reader

arc doesn't even pass its own challenge. "link unknown or expired"... great.

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?

JS Arc interpreter? Hey, if they can do it for Haskell…

http://github.com/johang88/haskellinjavascript

;)

Nostrademons wrote one, but it's pretty old, and I think the site is down.

http://arclanguage.org/item?id=1629

It's still up at http://jonathan.tang.name/files/arclite/index.html

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.

Update: I had to keep lowering the threshold to avoid server stalls. Currently at 50, where the site seems more stable.

Reply on news.ycombinator.com