Hi Andrew, I read your 2005 note, and I do not understand
>I expect the following execution trace > >(A | B) C (D | E) F > >|* - means processes can execute in parallel. *> >It is okay to see B finish before A. However it is >wrong to see C finish before B and A finish. Do you mean C starts after (A|B) finish, or they all start together, or ..? Larry On 10/21/08, Andrew Francis <[EMAIL PROTECTED]> wrote: > > Hi Larry: > > > 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. > > This is what I had in mind. A sketch. > > def producer(synchronizer): > try: > # do some computation > synchronizer.signal(result) > except Signalled, data > # oops the consumer has moved on.... maybe > # I should gracefully terminate..... > > > def consumer(synchronizer): > output = synchronizer.wait() > # okay, let us do some stuff with the output > > synchronizer = Synchronizer(numberOfProducers) > stackless.tasklet(consumer)(synchronizer) > for .... : > stackless.tasklet(producer)(synchronizer) > > Most of the effort is in defining the right behaviour..... > > Once again, my experiences are when you naively use channels, it is easy to > get in trouble. A construct like receive_first() looks difficult to > implement, in comparison to a synchronizer. > > Here is a thread from December 2005 (2005!) > > http://www.stackless.com/pipermail/stackless/2005-December/000290.html > > Cheers, > Andrew > > > > > > > > >
_______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
