[squeak-dev] Debugging of other processes with wait
Robert Withers
robert.withers at pm.me
Sat Aug 1 15:54:59 UTC 2020
Hi Jakob,
On 7/28/20 3:50 PM, Jakob Reschke wrote:
> Forward reply to the list... seems like something has changed in the
> Gmail interface and I have not yet adapted to it.
>
> Am Do., 23. Juli 2020 um 20:01 Uhr schrieb Robert Withers
> <robert.withers at pm.me>:
>> Although the Promise defined in Kernel-Processes has #wait protocol, this is really an anathema to Promise-style control flow. The #whenResolved: protocol should be used to register a reactor and no waits should occur.
>> [...]
>> Promise-style control flow does not use mutexes nor semaphores. So I believe the fundamental model here is misused.
>> [...]
>> So it is your intention to "move away from promise-style control flow." then I would suggest not using a Promise.
>>
> That's right, but right now I have some dialogs implemented in a
> Promise style and want to implement a use case without promise style,
> so I have to literally adapt when invoking the dialog if I don't want
> to write all of it anew immediately.
I am faced with a similar porting activity to bring SSL and SSH over
onto the ThunkStack architecture.
How do you dialogs function with a promise interface? Could you describe
what you have done here, please?
> Our current Kernel Promise is a two-headed beast:
Interesting.
> for one it wants to
> be a Promises/A+ implementation,
Even this is a concurrency model with #send:/#then: protocols.
> but originally it's purpose seems to
> be only to support #future sends.
Which seems to have nothing at all to do with whether it is a Future.
It's a Promise. This that you call future, is merely scheduling after a
delay, right?
> Promises/A+ is targeted at
> asynchrony in single-thread languages like JavaScript,
This is a definite concurrency protocol which allows for multi-agent
interaction. I would suggest it is inherently a concurrency model,
though it may not be explicit about single threaded vats. Smalltalk is
also single-threaded on the processor.
> while futures are for multi-thread languages like Smalltalk.
I see the #then: protocol as the model for promises in multi-thread
environments. Not the scheduling.
> So Kernel Promise now
> tries to serve both single-thread computing (UI process only) and
> multi-thread computing (multiple Smalltalk processes).
This multi-thread goal is the source of the #wait protocol, yes?
I would like to suggest integrating PromisesLocal into the trunk image.
I will send a separate email, describing my proposal.
Kindly,
rabbit
More information about the Squeak-dev
mailing list
|