Re: Continuation based app servers
- From: Pascal Bourguignon <pjb@xxxxxxxxxxxxxxxxx>
- Date: Thu, 31 May 2007 14:33:31 +0200
Slava Akhmechet <coffeemug@xxxxxxxxx> writes:
Here is what I want to support:
(defun authenticatedp ()
(if *authenticatedp*
t
(do-modal #'login-or-register)))
(defun some-action ()
(when (authenticatedp)
(do-action)))
The key is 'do-modal' - a construct that shows a login page (which can
manage rounds of user interaction), and returns the result of the
login operation as if it were a simple function call.
I don't need continuations to achieve this functionality. The trick,
saving the stack, can be done with threads. Whenever 'do-modal' is
called, it can spawn a thread and assign it to the current
session. All interaction will then be executed by that thread while
'do-modal' blocks the original thread and waits for some signal from
the new one.
It can work.
The problem you have is that there is a limited number of threads
possible in a process (around 300 or 400). Therefore you can handle
only a limited number of concurent modal sessions (around 150 or 200
if you call recursively do-modal only once per session).
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
.
- Follow-Ups:
- Re: Continuation based app servers
- From: Slava Akhmechet
- Re: Continuation based app servers
- From: fireblade
- Re: Continuation based app servers
- References:
- Continuation based app servers
- From: Dustin Withers
- Re: Continuation based app servers
- From: Slava Akhmechet
- Continuation based app servers
- Prev by Date: Re: code critique
- Next by Date: Re: code critique
- Previous by thread: Re: Continuation based app servers
- Next by thread: Re: Continuation based app servers
- Index(es):
Relevant Pages
|