[squeak-dev] [Proposed] include PromisesLocal in trunk

Robert Withers robert.withers at pm.me
Sat Aug 1 16:09:12 UTC 2020


Good afternoon!

I wish to offer a proposal for discussion to include PromisesLocal into 
trunk and to replace the implementation of Promise/BrokenPromise with 
PromiseERefs and BrokenERefs. The underlying concurrency model has 
explicit use of an event loop in PromisesLocal. The code size is minimal 
but adds the Promises/A+ specification to Squeak, that can be extended 
into a remote reference solution and an Agent communications 
architecture. Exceptions are processed.

I want to define a VatSemaphore that allows the user to #wait/#signal, 
and they get 'immediate' control flow which most folks find as a valid 
way to describe steps taken.Under the covers the VatSemaphore is 
connected to the Vat, as an element in a forthcoming continuationPool. 
So a Vat is {stack, queue, pool, eventLoop}. When #wait is sent, the 
continuation is captured and placed in the pool and the vat's event loop 
continues with the next event. When #signal is sent to this 
VatSemaphore, the continuation is scheduled: in the queue and removed 
from the pool. The event loop will process the continuation.

>> On 7/28/20 3:41 PM, Jakob Reschke wrote:
>> My other suspicion is that we would nevertheless need an extended 
>> debugger to deal well with such eventual control flow. A debugger 
>> with a "step to resolution" or so that steps to the point where the 
>> messages are eventually answered, or the receiver even activated.
> I think that this is a great idea!

Research in this direction would be AWESOME!



On 8/1/20 11:39 AM, Robert Withers wrote:
>> On 7/28/20 3:41 PM, Jakob Reschke wrote:
>> Current Kernel Promises are also not good at that without sprinkling 
>> breakpoints... This and the dreadful error handling ("well so I 
>> forgot the block argument for the callback again and got an error 
>> from value:, now how do I find out in the debugger which method even 
>> contains my wrong block?!?"
> What if the debugger could allow you to browse reactor creation 
> methods? Where is the closure created?

I can imagine an implementation of EIO 
(http://wiki.erights.org/wiki/EIO_Redesign), Eventual I/O, that has a 
#whenAvailable: semantic. Then the UI event loop is just an EInputStream 
and we could flip the entire system over to using a promise architecture.

Kindly,
rabbit




More information about the Squeak-dev mailing list