On Sat, Oct 13, 2018 at 6:32 PM George Neuner <gneun...@comcast.net> wrote:
> Remember that a continuation is not a simple thing - in order to resume a
> program from a particular point, the entire state of the current call chain
> must be preserved: the globals, the call stack, the thread state, etc. ad
> nauseam. If you start to consider things like JIT'd code, shared memory,
> message queues, open files, network connections, etc., the list of what
> needs to be preserved is, in theory at least, unbounded.
>
This isn't quite right: continuations close over the values of local (i.e.
lexical) variables, control flow/the call stack, and continuation marks
(most prominently, parameters in the sense of `parameterize`), but they do
not save global or module-level variables or the store in general.
As an illustration, this program prints the serialized form of one of
`#lang web-server`'s continuations. You can see that the serialized
representation includes `'lexical-value` but not `'global-value`.
#lang web-server
(require racket/serialize)
(define global
'global-value)
(call-with-web-prompt
(λ ()
(let ([lexical 'lexical-value])
(call-with-serializable-current-continuation
(λ (k)
(println (serialize k))))
lexical)))
But now imagine that 10 different threads have entered that same call chain
> and reached that same continuation point. Now 10 separate instances of the
> call stacks - and everything they reference - have to be preserved to
> support the continuations.
>
On the same note, I think this depends on what you mean by "reference". If
each continuation closes over a reference to the same shared data
structure, the shared value shouldn't be copied. On the other hand, if they
construct 10 equivalent values (`equal?` but not `eq?`), then yes, all 10
will be retained, just as if you'd stored them in a mutable hash table
without continuations involved.
> Heavy use of "long-lived" [for some definition of "long"] continuations in
> a program can eat up huge amounts of memory.
>
Despite what I just said, I know that stateful servlets do use a lot of
memory to retain native continuations in memory: the "Automatically RESTful
Web Applications" paper says that stateless servlets use ≤10% of the memory
of stateful equivalents.
> Web continuations are kin to general (call/cc) continuations.
>
The stateful web primitives are implemented using `call/cc` and native
continuations. The stateless versions use
`call-with-serializable-current-continuation` and the serializable
representation of continuations from `#lang web-server`.
> So in the scenario above, the state of threads that are [arbitrarily long]
> waiting on user actions might be GC'd to free up memory.
>
I think this is what you're saying, but, to be totally clear, with
stateless `#lang web-server` servlets, all server-side state is freed once
the response is sent to the client. (Of course, you can still mutate global
state, write to files or databases, etc. by stepping outside of the
continuation system, but you don't need to do any of those things.)
-Philip
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
