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@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