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).

Cheers,
Josh


> 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.
> 
>> Cheers,
>>  - Andreas
>> 
>> 
> 
> 
> 
> -- 
> Best regards,
> Igor Stasenko AKA sig.
>