I was talking about class Continuation and how its used in the context
of Seaside.  In that context, I have observed, for example, a critical
block being entered prior to snipping a Continuation off the stack (to
be resumed later), thus leaving Mutex's on the stack stuck in their
wait state, and blocking subsequent requests.

On Wed, Jan 15, 2014 at 11:23 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
> No they don't. Continuations have nothing to with mutexes at all. I'm
> not sure that we're talking about the same thing when we say
> "continuation".
>
> When _I_ say "continuation" I mean, effectively, the call stack: it's
> the thing to which the result of the current activation record will
> return a result. You can thus consider a _delimited_ continuation as a
> chunk of stack. #on:do: delimits the stack using a primitive (19?). An
> _undelimited_ continuation is the entire call stack from the very
> beginning of a program. thisContext + all its senders is the closest
> we have to such a thing in Smalltalk: since all call stacks eventually
> hit nil, they're all delimited by _something_.
>
> And we use continuations _all the time_ in Smalltalk, or things that
> may be trivially expressed in delimited continuations: from a CS
> perspective delimited continuations and resumable exceptions are
> equivalent, in the sense that each may implement the other.
>
> frank
>
> On 15 January 2014 16:30, Chris Muller <ma.chris.m at gmail.com> wrote:
>> Continuations are also bad because they leave Mutex's in their wait
>> state.  That, alone, is a show-stopper for me for using continuations.
>>
>> On Wed, Jan 15, 2014 at 10:14 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
>>> Yes, I know. But that just means that implementing a bad idea (modal
>>> dialogs) with some random piece of tech (continuations) is a bad idea.
>>>
>>> I thought you meant that continuations _implied_ something negative
>>> about UI design by their very nature. But it sounds like that's not
>>> what you meant. Which is good :).
>>>
>>> frank
>>>
>>> On 15 January 2014 15:56, Chris Muller <asqueaker at gmail.com> wrote:
>>>> Frank, by my limited knowledge, the call: / answer API of Seaside used
>>>> a Continuation to allow a modal component to be rendered on top of
>>>> other components until #answer: is sent by one of the callbacks.  That
>>>> provides stateless web-apps the ability to do desktop-like modal
>>>> "dialog" boxes that can return values to the calling component.
>>>>
>>>> On Wed, Jan 15, 2014 at 2:34 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
>>>>> On 15 January 2014 03:10, Chris Muller <asqueaker at gmail.com> wrote:
>>>>>>>> On 14-01-2014, at 5:17 PM, Colin Putney <colin at wiresong.com> wrote:
>>>>>>>> > Meh. Don't worry about it. Seaside is obsolete anyway.
>>>>>>>>
>>>>>>>> Really? I haven’t taken any interest in web development in ages; what’s
>>>>>>>> the replacement for Seaside?
>>>>>>>
>>>>>>>
>>>>>>> It's not that there's a replacement. It's more that the problem it solves
>>>>>>> isn't a problem anymore.  Continuations were a brilliant way to manage apps
>>>>>>> that were basically dynamically generated web pages connected via links and
>>>>>>> forms. But Javascript runtimes have gotten way, way faster, more robust and
>>>>>>> more standardized in the last 10 years.  Modern web apps are more of a
>>>>>>> client-server model: the UI rendering and interface logic is all done in
>>>>>>> Javascript running in the browser, and it communicates with the server by
>>>>>>> shuttling JSON back and forth over HTTP. In that sort of a system,
>>>>>>> continuations don't provide any benefit, and the drawbacks start to become
>>>>>>> significant.
>>>>>>
>>>>>> Continuations were never good for UI design anyway.  Modal.
>>>>>
>>>>> I don't understand - what does UI modal-ness got to do with with
>>>>> continuations? (Or: the whole of Squeak is fundamentally built on
>>>>> continuations (Process, ContextPart).)
>>>>>
>>>>> frank
>>>>>
>>>>
>