3 ms·
"On the other hand it is a straw man because you would not use continuation for navigation in real-world production web sites. You would have to store a continu
by papersmith 19y ago
"On the other hand it is a straw man because you would not use continuation for navigation in real-world production web sites. You would have to store a continuation for every hit on the site forever, which is clearly not scalable."
I think if you are not using first-class continuation and are rolling your own CPS-style libraries, you can make the continuations serializable. Then you can save them on a LRU cache like memcached, to disk, or pass them to the client, depending on your performance requirements.
- olavk 19y agoAgreed, if you serialize the closure and append it to the URL, you solve the problem. I actually proposed this fix over in the Arcforum yesterday: http://www.arclanguage.com/item?id=1760 http://www.arclanguage.com/item?id=1760 But if you keep the closure on the server, whether memcached or on disk, you still have the problem that you have to keep storing a growing amount of closures forever.
- papersmith 19y agoI think for most public web sites, keeping sessions in a LRU cache like memcached shouldn't be a problem, since it automatically purges the relatively inactive sessions. Assuming each session uses up 100k, which is a lot if the user is not writing a novel, you can still keep 10,000 active sessions in 1GB of memory. If you think the sessions are purged too early, you can add more ram, or more boxes, since memcached is distributed. Last I checked facebook had a 3TB memcached cluster. But ya, if the sessions are small enough you might as well pass them to the clients.