On Thu, Apr 23, 2015 at 1:35 PM, David Vanderson <david.vander...@gmail.com> wrote: > >> 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?
The values of the parameters are saved in the continuation and inherited from the thread. Jay >> >> 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. -- Jay McCarthy http://jeapostrophe.github.io "Wherefore, be not weary in well-doing, for ye are laying the foundation of a great work. And out of small things proceedeth that which is great." - D&C 64:33 -- 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.
