Hi Stefan, On Fri, 05 Aug 2005 07:20:36 +0100, Stefan Rank <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
