Advanced concurrancy

[Matt Hammond]

Hi Stefan,

On Fri, 05 Aug 2005 07:20:36 +0100, Stefan Rank <stefan.rank at ofai.at>  
wrote:

>>> So do you plan on including a kind of scheduler-aware blocking
>>> communication (like the `channels` of the `tasklets` in stackless)?

Not at the moment. The kinds of applications we've mainly been looking at,  
whilst developing, have been multimedia data-flow oriented, so blocking  
communication would be used as a rate limiting mechanism. However, we've  
found we can achieve that by putting explicit feedback links in.

I think we are also trying to stick with the asynchronous way, if  
possible, because it may well make things simpler and more efficient when  
it comes to distributing components across processes / networked  
computers. Synchronous links will lead to handshaking latencies, more data  
needing to flow etc. IMO that kind of facility could always be built on  
top - for example - using a feedback inbox->outbox path to 'request' new  
data ... if you really need it.

... it also simplifies the scheduler. We've tried, so far, to keep the  
underlying microprocess model decoupled from the components and  
inbox/outbox layer. That said, that may have to change eventually!

> this communication infrastructure is definitely a Good Thing (TM), the  
> same holds for a standard environment or registry (wassitsname, your CAT  
> thing) as you need at least one well-known point of reference in a  
> 'distributed' system.

yep its a CAT (Coordinating Assistant Tracker). Nothing to do with the  
project logo ... nooo! :-)

> <dreamingmode>
>    now if someone could only cut the gordian knot of the
>    GlobalInterpreterLock to make all this really concurrent... and then,
>    when she's at it, allow transparent distribution of components in a
>    network... ;-)
> </dreamingmode>

I'll second that!

regards


Matt
-- 

| Matt Hammond
| R&D Engineer, BBC Research and Development, Tadworth, Surrey, UK.