What I want to do is:
create a hash representing the return object
- data to return
- URL for next page function (if applicable)
- URL for prev page function (if applicable)
convert the hash to a jsexpr
send/suspend/dispatch the jsexpr
#lang web-server/insta
(require json)
(define (response/json jsexpr)
(response/full 200 #"Okay" (current-seconds) #"application/json"
(list)
(list #"" (jsexpr->bytes jsexpr))))
(define (start request)
(define idx 0) ; state stored in continuation
(define (show-prev-page request)
(set! idx (sub1 idx))
(show-page))
(define (show-next-page request)
(set! idx (add1 idx))
(show-page))
(define (show-page)
(send/suspend/dispatch
(lambda (embed/url)
; make hash representing the return object
(define js-hash (hasheq 'data idx
'url-next-page (embed/url show-next-page)
'url-prev-page (embed/url show-prev-page)))
; send the response, a hasheq is already a jsexpr
(response/json js-hash))))
(show-page))
Does this do what you want?
My understanding is that when you do send/suspend*, the continuation
is saved, and the thread finishes. The continuation and thread are
not bound together. So when a request comes in to continue that
continuation, it will be a different (new?) thread that runs it.
That's fine: the "term" thread is overloaded. I understand that
Racket threads are user-land scheduler activations [I think that's the
term] ... i.e. just multiplexed continuations. My point was that
there is some execution context hanging around when the "thread" is
suspended and it wasn't clear that it would be GC'd if/when all the
thread's send/suspend "continuations" expire.
I don't think any context hangs around apart from the continuation. This
is close to my knowledge limit though.
Jay - is there any connection between a saved continuation and the
thread that created it?
There's nothing that says definitively that the servlet continuation
manager is holding the *only* references to the thread context [or
the only strong references if that's more applicable] - somewhere I
recall Jay explaining the structure being something like:
server->custodian->custodian(s)->thread(s)->user-stuff ???
and it is not clear where the continuation manager lives in the
hierarchy [ though I can guess ].
Can you give an example of the processing that you want to know has
been finished? Do you want the thread serving the request to do some
processing after sending the response?
The thread can be suspended after sending a response. What I'd like,
though, is for it to wake up again and log some exit data when all
continuations expire.
I'm not sure I understand the motivation here. Can you give an example
of the kind of exit data you want to log?
That could - with difficulty - be done from an exception handler if
the thread is terminated by exception as opposed to simply
evaporating, and also provided that I know what exception(s) to catch
or events to wait on. One of the issues I've had with real-world
Racket programming is determining what exactly happens when things go
wrong. A catch-all exn or exn:fail handler doesn't cut it when you
need more detail, and, of course, the hierarchy is extensible so
things may be thrown that aren't documented. "read the code" is fine
for research, but it isn't a realistic real-world answer - there's too
much code and not enough time. As I said to Jay recently, I wouldn't
know where to look even if I had the source.
Thanks,
Dave
--
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.
