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