[squeak-dev] Re: Future examples (Re: Inbox: #future keyword for
asynchronous message invocation)
josh at schwa.ca
Fri Dec 18 11:35:00 UTC 2009
On Dec 18, 2009, at 2:35 AM, Igor Stasenko wrote:
> i don't know much about implementation detail, but
> binding every future sends to a single process - Morphic UI process
> (and in this way you of course relaxing the concurrency problems)
> creates a potential bottleneck, since all future sends is using single
> thread for evaluation , means that:
> foo future fooz.
> bar future baz.
> will unable to run concurrently,
This assumes that the two messages are scheduled for execution on the same event-loop. In practice, we have many dozens of distinct event loops, each running in it's own Process. The trick is to be able to determine on which event-loop a future message should be scheduled. We commonly use two approaches, but there is lots of room for exploration. One approach is to use a per-Process property to look up the event-loop; this isn't that different from asking "Project current". Another is for an object to directly know where to schedule a message. For example,
(aHydraProxy future doSomeWork: input) whenResolved: [:result | self future workWasFinished: input withResult: result]
could cause the #doSomeWork: message to be sent across a Hydra channel, where it would be scheduled for execution on the appropriate event-loop. When the work is finished, the remote Hydra image sends the result back on another channel, causing the promise to be resolved. We have real concurrency even if #workWasFinished:withResult: is scheduled on the Morphic loop (again, it needn't be).
> despite the potential possibility to
> safely run without interference with each other.
> So a given scheme ends using a single global synchronization semaphore
> to handle all future sends, and that's not very good.
> But i agree, its simple, yet it far from being useful for employing a
> highly scalable concurrent schemes.
>> - Andreas
> Best regards,
> Igor Stasenko AKA sig.
More information about the Squeak-dev