[squeak-dev] Call-cc [was: GUI threads (was: Replacing or enhancing or supplementing Morphic))

Frank Shearar frank.shearar at gmail.com
Fri Mar 3 16:35:32 UTC 2023


On Fri, 3 Mar 2023 at 07:41, Eliot Miranda <eliot.miranda at gmail.com> wrote:

>
> On Mar 2, 2023, at 11:54 PM, rabbit <rabbit at callistohouse.org> wrote:
>
>
> 
> Does a block closure preserve its creating context?
>
>
> Yes, but not the creating context’s continuation.
>
> Walking the future tree, we could collect the back tree of creating
> contexts to establish an historical tree. I say tree because reactor #1 was
> then: immediately after causal send leading to the exception, and the
> promise got passed around and another belly cat sent a then: for reactor
> #2, both in the same promise’s pendingSends queue. Therefore the historical
> view of a future tree is also a tree. So the eventual debugger has a future
> / historical toggle. And we debug the tree and not the stack.
>
>
> This is a good idea and could be fine efficiently with the current VM
> architecture. (*) Promises would be created with the equivalent of
> “call-cc”, (*) scheme’s call-with-current-continuation.  I’ve discussed
> this with Andreas, Avi Bryant, Colin Putney, and others over the years. It
> would elevate the level of comprehensibility in future/promise based
> systems significantly.
>

As long as "call-cc" means "delimited continuations", yup yup. (See
https://okmij.org/ftp/continuations/against-callcc.html and
https://okmij.org/ftp/continuations/undelimited.html#delim-vs-undelim)

frank


> Further, because the exception system is first-class, handler search could
> be extended from the promise’s stack to its enclosing continuation’s stack,
> which would make managing errors in promises much easier; one would not
> have to establish an error handler where each promise is created, but could
> establish a single error handler in the thread that creates promises (etc,
> this can nest if desired/so implemented).
>
>
> Yet, reactor #1 could also have been sent outside the causal send context.
> So we may still want to hold the causal context in the promise / eMsgSend
> object.
>
>
> (*) an implementation note for those looking fir a juicy VM project. The
> essence of call-cc is stack duplication. C.f. the explicit stack
> duplication in Seaside’s delimited continuations. When call-cc occurs
> effectively the entire stack is duplicated so that both the creating and
> the created thread can continue. (for promises this allows us to see where
> the promise originates long after the creating thread has continued and
> returned from where it created the promise, which is why this helps with
> debugging).
>
> I am told that in efficient  scheme implementations stack duplication is
> made lazy. Essentially a flag is set in an activation record that does
> call-cc that is checked at return time. This causes the activation to be
> preserved for the call-cc continuation and set for the activation record
> being returned into, lazily duplicating only those activations that are
> actually returned from. Neat.
>
> In the Cog VM, executable activation records (contexts) live in a special
> form on small stack pages in the stack zone. This is done both to avoid
> having to create context objects until unavoidable (home contexts for
> blocks, reifying the contexts stack for the debugger, etc), abc to allow
> the JIT to optimize sends using conventional call instructions.  Each stack
> page is large enough ti hold about 40 normal sized activations (& only one
> of two huge activations).  Having the equivalent of call-cc duplicate the
> entire stack page, and propagate down the “preserve/duplicate me” flag to
> the next page, could be extremely efficient, avoiding the relatively
> expensive return-time check of scheme implementations.
>
> Anybody seriously considering building in Squeak above Cog things like a
> massively parallel compute architecture, or making things like Teatime (in
> Croquet) much easier to debug, would do well to take such an approach.
>
>
> BTW, Jecek’s explanation of the concurrency architecture in Morphic is
> masterful and should at least be copied into the help browser.  Thank you,
> Jecel.
>
>
> 🐰
>
>> Have a good one; keep it, light.
> Kindly, rabbit . .. … ‘…^,^ 🐇🐇🐇
>
> Sent from Callisto House mobile - Ganymede
> :: decentralized mobile homeless solutions ::
>
>
>
>
> On Fri, Mar 3, 2023 at 02:42, rabbit <rabbit at callistohouse.org> wrote:
>
> This was a little confusing my apologies.
>
> This example
>
>      (anObject eventual identityHash * 10)
>
> I incorrectly labeled promise chaining. It’s more properly called in the
> literature as pipelining, where we send a follow on DNU message to
> anENearPromise. Let’s break it down
>
> anObject eventual returns anENear
>
> Sending identityHash schedules it’s EventualMessageSend, in the Vat, and
> reteruns anENearPromise.
>
> Immediately following this promised send, we eventually send a * 10. This
> stores it’s EventualMessageSend in the ENearPromise’s pendingSends queue
> and returns anENearPromise #2.
>
> This is Promise Pipelining.
>
> In my opinion right now it is more convenient to develop in a synchronous
> manner in Squeak because the debugger in its current state is better suited
> for that. It does not support you very well with Promises, deferred UI
> messages, spawned processes and the like... And when some of the tools that
> you are used to do not support you well anymore, it does not feel good.
>
> Yes, indeed. I’ve been thinking about this. Deep in a send tree, an
> exception occurs. We would like to see a stack representation of some kind.
> What kind?
>
> First guess is the stack of sending contexts leading to the exceptional
> send. However, good Eventual Sending Style would see calling sends to
> eventuality send its work and exit. Therefore, it is highly likely there is
> no stack available.
>
> Is it feasible to store sends leading down to the exceptional send? This
> is a disconnect that could seriously affect our ability to
> debug effectively.
>
> So what sort of stack could we build? As this only happens when debugging,
> we could afford to seek the stack for the EventualMessageSend activating
> the immediate stack. Store the ENearPromise that corresponds to the
> eMsgSend’s resolver withe the eMsgSend. Then when the activating eMsgSend
> is found, access the promise’s pendingSends and collect the registered
> reactors from calls to the promise #then: / #whenResolved: /
> #whenRejected:. They themselves have promises with pendingSends, so a tree
> of future sends could be established. These should all get #smashed: from
> the exceptional send, once resumed into the future.
>
> Andso, it seems to me we could struggle to produce an historical stack,
> but we could provide a futuristic promise tree.
>
> I’m thinking we really need the historical stack. For example an argument
> is provided that fails. Where did this argument come from. We need to
> backup and regenerate the argument. Without a historical stack I don’t see
> how that works.
>
> Therefore, I think we may need to preserve the sending contexts. What are
> the implications to do this? I don’t know.
>
> 🐰
>
> On Wed, Mar 1, 2023 at 15:23, rabbit <rabbit at callistohouse.org> wrote:
>
> Let’s make better Turbinado Sugar for our café con leche! The #* is
> sent to the result promise from #identityHash’s esend. This promise’s
> #doesNotUnderstand: redirectMessage: of the ‘* 10’ and returns the 2nd
> promise. The argument to show: cannot be an eventual ref, at this time, so
> a then: with a reactor is required. No promise chaining will work.
>
>     (anObject eventual identityHash * 10)
>         then: [:codeMag |
>             Transcript cr;
>                 show: ‘code order of magnitude = ‘, codeMag].
>
> 🐰
>
>> Have a good one; keep it, light.
> Kindly, rabbit . .. … ‘…^,^ 🐇🐇🐇
>
> Sent from Callisto House mobile - Ganymede
> :: decentralized mobile homeless solutions ::
>
>
>
>
> On Wed, Mar 1, 2023 at 14:52, rabbit <rabbit at callistohouse.org> wrote:
>
>
>
> On Wed, Mar 1, 2023 at 14:18, Jakob Reschke <jakres+squeak at gmail.com>
> wrote:
>
> Event-loop based UI development is usually a good strategy. It is how
> Windows works at the foundations... I know that this will sound rather like
> an argument against it for some people. ;-P
>
> lol! Certainement! Yet they built the Midori eventual sending OS [1].
>
> The question is whether it is convenient to program like that. All parts
> involved must account for the asynchronicity. It may be more convenient to
> just send a Smalltalk message rather than using addDeferredUiMessage: and
> wrapping your intent in a block, but the code that comes after that line
> looks different, too.
>
> Yes indeed. The EST: Eventual Sending Style.
>
>     ((an object eventual send: #identityHash)
>         then: [:code | code * 10])
>             then: [:codeMag | Transcript cr; show: ‘code order of
> magnitude = ‘, codeMag].
>
> Looking into sugar, with ESqueak, where EAbstract>>#doesNotUnderstand:
> eventually sends the msg like a trampoline:
>
>     (anObject eventual identityHash
>         >>: [:code | code * 10]
>         >>: [:codeMag | Transcript cr; show: ‘code order of magnitude =
> ‘, codeMag].
>
> Where the as yet unimplemented ENearPromise>>#>>:>>: would be
>
>     ^ (self then: reactor1)
>         then: reactor2.
>
> Of course instead of a block the reactor could be (an anonymous) subclass
> of WhenResolvedReactor and set a closure object in initialize.
>
> Especially if you need a result/response to continue your overall
> computation.
>
> I was thinking of a possible marking of a closure as #immediate to turn
> all eventual sending within as immediate calls.
>
> You may be inclined to use Promises there, where you would not do that
> otherwise, for example.
>
> Right.
>
> In my opinion right now it is more convenient to develop in a synchronous
> manner in Squeak because the debugger in its current state is better suited
> for that. It does not support you very well with Promises, deferred UI
> messages, spawned processes and the like... And when some of the tools that
> you are used to do not support you well anymore, it does not feel good.
>
> An excellent observation, Jakob! Tool support for eventual sending would
> be a must, specifically the debugger.
>
> I think this exposes the coordination problem, I guess we could call it.
> How does one intrepid souk debug control flow among independent event
> processes?
>
> Given success with these issue, does it make sense to keep eventual
> sending as a candidate?
>
> Would it not allow controller / view / model interactions to be thought
> about clearly?
>
> Thanks for your consideration.
>
> 🐰
>
>
>
> Am Mi., 1. März 2023 um 19:40 Uhr schrieb rabbit <rabbit at callistohouse.org
> >:
>
>> Awesome! Jecel, I’m quite curious to hear your thoughts on eventual
>> sending. EVERYBODIES thoughts, really. Is event-loop eventual sending a
>> feasible style / function for UI development?
>>
>> 🐰
>>
>>>> Have a good one; keep it, light.
>> Kindly, rabbit . .. … ‘…^,^ 🐇🐇🐇
>>
>> Sent from Callisto House mobile - Ganymede
>> :: decentralized mobile homeless solutions ::
>>
>>
>>
>>
>> On Wed, Mar 1, 2023 at 13:00, Jecel Assumpcao Jr <jecel at merlintec.com>
>> wrote:
>>
>> David T. Lewis wrote on Tue, 28 Feb 2023 20:39:54 -0500
>> > In MVC, each Controller has its own Process, and those processes are
>> > scheduled when needed as windows are activated. In Morphic, there is
>> > a single UI process.
>>
>> True, but misleading. Just like the VM has a single OS thread that it
>> multiplexes between image level processes, the single Morphic thread
>> pretends to run each morph in parallel at a known rate by repeated
>> sending #step to them.
>>
>> Because we know that only when #step for one morph is finished that
>> #step will be sent to the next morph, we have been programming as it
>> morphs did not execute in parallel even though that is what the model
>> was supposed to be. That is why we get in trouble when things happen
>> outside of the GUI scheduler.
>>
>> In Self you have have more than one Morphic window and each gets its own
>> GUI thread, but they are unlikely to share the same objects so we don't
>> notice the problem. You can also have multiple windows in different
>> machines viewing the same "world" and in that case they all share a
>> single GUI thread.
>>
>> -- Jecel
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20230303/8aa6a664/attachment.html>


More information about the Squeak-dev mailing list