Trust the GC

Via Don Box, I see that Ian Griffiths has a few issues with continuation based web applications. One issue he brings up is resource usage:

Sometimes the user just walks away. I might get part way through the purchasing sequence on a web site and then decide to stop. The web server never gets any positive indication that I closed the browser window. It merely stops hearing from me.

What does this mean in a world where I’m using continuations to help model user journeys as sequential code? It means that sometimes my functions just stop part way through without reaching the end.

On the plus side, it is predictable where this will happen: it can only occur at boundaries where I choose to construct a continuation and then relinquish control for now. But at every such boundary, I need to be aware that sometimes, the continuation will never execute.

This is very much not analogous to the function returning or throwing an exception. In the world of our chosen abstraction - that of sequential execution of a method - it looks like our thread has hung.

The problem with this is that a lot of the techniques we have learned for resource management stop working. Resource cleanup code may never execute because the function is abandoned mid-flow.

I don't know why this would be a problem, given a halfway decent GC system. The stale session will eventually time out, and take any lingering state down with it. I can see being worried about the memory required by this, in the face of a lot of users, but not in the basic mechanics. In a Smalltalk server - either VisualWorks or Squeak based - Ian's worry is a non-problem. Then he has an issue with thread affinity:

Traditionally, any particular invocation of a function runs on a single thread from start to finish. We’re not accustomed to mid-function thread switches, and it will render some hitherto safe practices unworkable. Using objects with thread affinity will become particularly hazardous, for example - we will need to be mindful of the potential switch points and make sure we never use such objects across such a boundary.

Actually, in this server, I've got requests that end up invoking new processes now, without continuations. They are managed with a class called Promise, but it's pretty simple - it's just a matter of delaying the waiting process and using a signal to inform the waiting process that results are ready. The pre-existing class makes that easy for me, but the code isn't hard to follow either way. Running multiple threads with shared objects is a comlex problem for any kind of application, whether continuations are involved or not.

Then he's got a long riff on how Continuations might break in the face of the Back button. Hmm - that was one of the problems that this approach was designed to solve. So far as I know, this simply isn't a problem in Seaside.