Advanced concurrancy

[Stefan Rank]

on 04.08.2005 11:15 Matt Hammond said the following:
> Hi Stefan,
> 
>>It seems as though all components basically have to do busy waiting now.
> 
> You are right - components are, for the most part, busy-waiting. Which
> is not a good thing!
> 
>>So do you plan on including a kind of scheduler-aware blocking
>>communication (like the `channels` of the `tasklets` in stackless)?
>>
[snip]
> 
> There is basic support for components to block, by calling the
> self.pause() method. From the next yield, this blocks further execution
> until
> data arrives on any inbox.
> 
[snip]

ah, i was searching for blocking on a specific inbox, but this is 
actually a saner approach i think. why should you block on one inbox and 
ignore data coming in on another...

> There are quite probably better mechanisms around - hence the
> distinction, in the code, between microprocesses and components.
> We'd be very interested if yourself or other people want to play with
> alternative communication & blocking mechanisms.

i think in-out channels is probably the best way for easy to manage 
comunicating processes.

> I'd hope that even if the components and postboxes model doesn't
> work out in the long run, the underlying generator based
> microprocesses code could still be of some value to others!

yes both levels will (it will take some time before i can use it 
here...), i think of it as a more complete version of some of the 
stackless features in standard python. (thanks again by the way)
the magic.greenlets have 'cooperative microprocesses', but lack the more 
pipe-like communication facilities and the independency of the 
generators+scheduler based approach.
the coroutine support in future pythons (see the generator PEPs) will 
probably make this easier... maybe::

   next_inbox_to_read = yield blockon(inbox1, inbox2)

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.

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