Lambda the Ultimate

Alex

that problem boils down to the problem of how to effectively marshall a continuation in PLT Scheme. "Automatically Restructuring Programs for the Web" by Graunke, Findler, Krishnamurthi, and Felleisen talks about that issue in the context of Web programs, and while it's oriented towards the idea that the marshalled continuation eventually goes to a hidden field on a web page, there's no reason it couldn't go to a database server shared by a web cluster instead.

I haven't asked, but I suspect the reason Felleisen doesn't discuss it in "Developing Interactive Web Programs" may well be because while "Automatically Restructuring Programs for the Web" sketches the problem's solution, there are a million little details and practical concerns that we haven't quite ironed out yet. Keep watching, though.

To continue the PLs as OSes theme, I would think they'll publish more about running servlets on server farms, when the PLT web server supports such distribution, and hides the complexity from the programmer.

Flatt is doing the PLs as OSes theme, but he's actually the PLTer least involved in the web-language branch of the PLT's research. Besides, I'm pretty sure that the PLT is actually pursuing the "Restructuring" way to implement send/suspend, considering that I'm the one writing the next paper on the subject. :) (I guess I should've mentioned that I'm Findler's graduate student.)

We've been working on fully realizing the compiler in "Restructuring" since the paper came out, and we're reasonably close to actually having something to show for that work. Once the compiler materializes, having clusters of web servers that all handle requests for the same CGI program will just be a matter of installing the compiled program on each computer -- all program state will be provided to whatever server happens to get the request on each transaction, so there's nothing else to do. This possibility is actually mentioned in some obscure corner of "Restructuring," I believe.

Matthias R - has anyone done any work on continuation-based web apps with SISC? I've been keeping an eye on it with an aim to port some of the ideas from Seaside (http://beta4.com/seaside2), but haven't yet had the time.

I have :)

The contrib/servlets cvs module of SISC contains helper code, some documentation and a complete web app example.

There really isn't much to it. The main complication, from a application programmer's point of view, is that one must ensure that every object reachable from the continuation is serializable. All SISC objects are serializable, but many ordinary Java objects are not. Specifically, HTTPRequest, HTTPResponse etc are not. Having any of these in your lexical environment breaks k serialization. The way to handle these is to place them in thread-locals (for which there is a convenient interface in SISC), which also has the advantages that one doesn't have to pass them around all functions and that they can easily be populated with new values when the k gets invoked.

> even if you can't marshal continuations, you just have to make > sure that all the requests for a session get sent to the same > server in the farm

indeed. afaik, generally app servers will try to avoid migrating session state between servers in a clusters by employing precisely this strategy. So session state only gets migrated in the event of node failure and severe cases of load imbalance.