Hi Andrew, We seem to have different ideas of what is simple. You propose exceptions, waits, signals, barriers, re-initialization, and presumably global signal values. This in my opinion is a whole Italian restaurant of spaghetti, and it sounds intrinsically global, which is poison to maintainable multiprocessing in my experience. Of course I could be wrong, having little experience with your way of doing things, except for standard C/Linux signals. (Have you ever tried setting anything up with occam manager and workers?)
The beauty of toplevel (stackless in the generic sense) processes communicating through channels is that they do not have to share resources OR KNOWLEDGE with other black boxes of the same construction but totally different function and/or history. This is what drivers try to be but never succeed. A manager based on ALT (or stackless_receive_first) can manage several of these black boxes - possibly of completely different types, like ethernet and disk - and apply optimal strategies to the data flow without digging deep into the driver code. But it has to be toplevel, not nested down deep like standard drivers. Larry On 10/16/08, Andrew Francis <[EMAIL PROTECTED]> wrote: > > Hi Larry: > > > --- On Wed, 10/15/08, Larry Dickson <[EMAIL PROTECTED]> wrote: > > > > I'm not sure I follow you here: the "mechanism that > > waits for multiple inputs and selects one of them" certainly does not > > look like a channel; it looks like a case statement. > > If I understand you correctly, I don't see a big difference (outside of > less machinery) between > > val = stackless.receive_first([chan1, chan2, ....]) > > and some construct, let us call it 'synchronizer' (loosely based on the van > Aalst workflow pattern - synchronizer). Usually synchronizers are synonymous > with barrier synchronization. > > val = synchronizer.wait(count) for N consumers, synchronizer.signal(some > value) for the producers. In your case, you can wait for one. > > chances are channels would be implemented under the hood.... > > If there is no consumer, a producer blocks. Once a synchronizer is > triggered, future producers will raise an exception on a signal until the > synchronizer is re-initialized. > > Again, I just feel that channels are powerful. However my limited > experience has been that scenarios where a single consumer waits on multiple > channels can be replaced with a simpler construct that is far more > controllable (and use few channels). > > Cheers, > Andrew > > > > > > >
_______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
