Hi Marc,
On 10/13/2018 3:37 PM, Marc Kaufmann wrote:
Hi George,
thanks, this is incredibly helpful.
On Sat, Oct 13, 2018 at 9:11 PM George Neuner <gneun...@comcast.net
<mailto:gneun...@comcast.net>> wrote:
:
3) results from the initial search are written into a dedicated
table in the database. The Racket program uses the same
continuation scheme and reads out pages of results on demand as in
(2). Now, since each database query is self contained, and the
user session does not require a persistent DB connection, a larger
number of users can be serviced with a small(er) pool of
connections. As in (2), all the result data is transitory in the
Racket program, so all that needs to be remembered are the
continuations.
4) results are written into a dedicated table as in (3). The
Racket program does NOT use continuations, but rather provides a
dedicated result fetch function - separate from the search
function - and generates page URLs which call that function with
appropriate arguments. Now, in addition to every DBMS query being
self contained, the functions of the Racket application also are
self contained - there is no persistent session state in the
Racket program.
OK, this does give one nice usecase where the distinction is clear. In
step 4, how should I think of the dedicated fetch function? Say I type
"continuations web servers racket" in the search, I get 3 pages, and
the dedicated table has three pages of 10 results each. Then the
search spits back the first page, as well as a function created on the
fly that, if provided with argument `page equal to 2 spits out the
second page, and if equal to 3 spits out the third? And the reason
this takes less space than a continuation for each page is what? I
guess it only needs to know the table location and page number, so if
there are 10 or 100 pages of results, the function still takes the
same amount of space, while I have 10 or 100 continuations. Is that
the difference with scenario 3)?
Yes.
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.
Imagine that at the point where the continuation is created, the program
is many levels deep in nested function calls, and many KB of data are on
the stack or referenced by it. 10 continuations taken at that same
location AND IN that same call chain won't add much because most of the
state is shared among them (only the resume location might be
different). In the stateful program, each continuation descriptor would
be just a small structure containing a handful of pointers to objects in
memory.
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.
Heavy use of "long-lived" [for some definition of "long"] continuations
in a program can eat up huge amounts of memory. The type of
continuation involved doesn't really matter - you can get into trouble
using just upward "escape" continuations (let/ec) as readily as you can
using general continuations (call/cc). Obviously you can "escape" with
a general continuation, but the typical usage of let/ec differs
substantially from the typical use of call/cc.]
Web continuations are kin to general (call/cc) continuations. Compiling
with the web-server language performs a number of transformations on the
program which make it possible to serialize continuation state and
save/restore it as needed. 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.
George
--
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.
