Larry: >Do you mean C starts after (A|B) finish, or they all start together, or >..?
Why did I write that in 2005? Yes C should start after A AND B finish. However the way the code is written, tasklets actually start before they block on channels. The point of that example was it was *very* easy to create a deadlock scenario with a relatively simple precedent graph implemented with just channels. Cheers, Andrew --- On Tue, 10/21/08, Larry Dickson <[EMAIL PROTECTED]> wrote: > From: Larry Dickson <[EMAIL PROTECTED]> > Subject: Re: [Stackless] Stackless based replacement > To: [EMAIL PROTECTED] > Cc: [email protected] > Date: Tuesday, October 21, 2008, 9:46 AM > 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 > > > > > > > > > > > > > > > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
