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> -- http://mail.python.org/mailman/listinfo/python-list