[Seaside] Seaside Internals

Stephen Pair stephen at pairhome.net
Mon Sep 8 18:11:06 CEST 2003


Avi Bryant wrote:

>On Mon, 8 Sep 2003, Stephen Pair wrote:
>
>  
>
>>Could you explain that a little more.  Do you mean that a continuation
>>cannot be concurrently invoked?  I suspect that's the case since it
>>doesn't look like you're copying the context objects in #restoreValues
>>...btw, didn't you copy the stack in previous versions?
>>    
>>
>
>Correct.  I did used to copy the stack, and I don't anymore - and so
>concurrent invocation of a continuation would be a mess.  Copying the
>stack had even more problems, however, because you simply can't track down
>all the places where there's an explicit reference to a context, and
>modify them to refer to the copy instead - I kept having to add more and
>more special cases like this to the Continuation code when I was stack
>copying.
>
>It's very common in continuation implementations to have the restriction
>"you can only invoke a continuation from the process in which it was
>captured".  That's even more limiting, although it would still be fine for
>Seaside.
>
>The "context tags" Anthony added reduce the number of places that a
>context object is directly referenced - so with those copying the stack
>would be more realistic.  I'm not convinced it's worth the added
>complexity, however.
>

Sigh...it is a quagmire.  The best hope for really solving this problem 
might be TeaTime.  The best continuation in Squeak is a snapshotted 
image on disk.  All state in the image is captured, and you can restart 
from that snapshot many times without worrying that the state one 
another activation will corrupt other activations.  What's needed is a 
transactional Squeak that would allow a very fast, efficient and 
fundamental snapshot of the current state of the system.

>>I just don't like the fact that sending #value to a Continuation trashes
>>the calling stack (with no unwind)...it seems like that shouldn't be
>>necessary.
>>    
>>
>
>It's not "necessary" - fork first.  I just can't think of a use case where
>you'd *want* to fork, so I'm curious what you have in mind.
>

Well, I could imagine a server could work like this:

[strm atEnd]
    whileFalse:
       [self dispatchRequest: self next]

In #dispatchRequest:, you could fork first then fire the continuation as 
you suggest (which iirc is essentially what happens with Kom/Seaside 
with some additional lookup and concurrency controls).  If you don't 
fork first, then you'll essentially kill this request handling service.  
To me, this seem to be such a common scenario that you want to consider 
adding a method to the protocol of Continuation to do two additional things:

a) invoke the continuation in a separate process
b) add controls to prevent multiple concurrent invocations

In this way, #dispatchRequest: might look something like:

dispatchRequest: aRequest
    (self lookupContinuation: aRequest) fire.

...where fire does a) and b).

- Stephen



More information about the Seaside mailing list