[Stackless] Stackless based replacement
andrewfr_ice at yahoo.com
Wed Oct 22 14:05:50 CEST 2008
>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
--- On Tue, 10/21/08, Larry Dickson <ldickson at cuttedge.com> wrote:
> From: Larry Dickson <ldickson at cuttedge.com>
> Subject: Re: [Stackless] Stackless based replacement
> To: andrewfr_ice at yahoo.com
> Cc: stackless at stackless.com
> 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 ..?
> On 10/21/08, Andrew Francis <andrewfr_ice at yahoo.com>
> > Hi Larry:
> > > We seem to have different ideas of what is
> simple. You
> > > propose exceptions, waits, signals, barriers,
> > > 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
> > 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
> > 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!)
> > Cheers,
> > Andrew
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
More information about the Stackless