3.2 Usage Considerations
A servlet has the following process performed on it automatically:
All uses of letrec are removed and replaced with equivalent uses of let and imperative features. ("lang/elim-letrec.ss")
The program is converted into ANF (Administrative Normal Form), making all continuations explicit. ("lang/anormal.ss")
All continuations (and other continuations marks) are recorded in the continuation marks of the expression they are the continuation of. ("lang/elim-callcc.ss")
All calls to external modules are identified and marked. ("lang/elim-callcc.ss")
All uses of call/cc are removed and replaced with equivalent gathering of the continuations through the continuation-marks. ("lang/elim-callcc.ss")
The program is defunctionalized with a serializable data-structure for each anonymous lambda. ("lang/defun.ss")
This process allows the continuations captured by your servlet to be serialized. This means they may be stored on the client’s browser or the server’s disk. Thus, your servlet has no cost to the server other than execution. This is very attractive if you’ve used Scheme servlets and had memory problems.
This process IS defined on all of PLT Scheme and occurs AFTER macro-expansion, so you are free to use all interesting features of PLT Scheme. However, there are some considerations you must make.
First, this process drastically changes the structure of your program. It will create an immense number of lambdas and structures your program did not normally contain. The performance implication of this has not been studied with PLT Scheme. However, it is theoretically a benefit. The main implications would be due to optimizations MzScheme attempts to perform that will no longer apply. Ideally, your program should be optimized first.
Second, the defunctionalization process is sensitive to the syntactic structure of your program. Therefore, if you change your program in a trivial way, for example, changing a constant, then all serialized continuations will be obsolete and will error when deserialization is attempted. This is a feature, not a bug!
Third, the values in the lexical scope of your continuations must be serializable for the continuations itself to be serializable. This means that you must use define-serializable-struct rather than define-struct, and take care to use modules that do the same. Similarly, you may not use parameterize, because parameterizations are not serializable.
Fourth, and related, this process only runs on your code, not on the code you require. Thus, your continuations – to be capturable – must not be in the context of another module. For example, the following will not work:
(define requests |
(map (lambda (rg) (send/suspend/url rg)) |
response-generators)) |
because map is not transformed by the process. However, if you defined your own map function, there would be no problem.
Fifth, the store is NOT serialized. If you rely on the store you will be taking huge risks. You will be assuming that the serialized continuation is invoked before the server is restarted or the memory is garbage collected.
This process is derived from the paper "Continuations from Generalized Stack Inspection" (http://www.cs.brown.edu/~sk/Publications/Papers/Published/pcmkf-cont-from-gen-stack-insp/). We thank Greg Pettyjohn for his initial implementation of this algorithm.