<div><br>> I solved my problem in 2005. I wrote a synchronizer construct similar to what</div>
<div>> I previously posted. I believe the uthread module had counting semaphores.</div>
<div>> I make the assumption that tasklets terminate soon after they join. This keeps</div>
<div>> the code simple. Under the hood, only one, not number of children + 1</div>
<div>> channels, are used.<br>><br>> That said, I think we are going around in circles....<br> </div>
<div>I agree, we seem to be talking past each other. For the realistic interpretation (start C after (A|B) finish), PAR uses no channels, no counting semaphores, and no tasklet survival after a join, thus no races. That certainly seems to qualify as simpler; but it needs the ability to spawn child tasklets that do the equivalent of an endp when they terminate. If this exists in Stackless, then the problem is trivial.</div>
<div> </div>
<div>Larry</div>
<div> </div>
<div><span class="gmail_quote">On 10/22/08, <b class="gmail_sendername">Andrew Francis</b> <<a href="mailto:andrewfr_ice@yahoo.com">andrewfr_ice@yahoo.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hello Larry:<br><br><br>>What is needed is the PAR construct: I do not believe any combination of<br>>channels can do the same exactly. If C starts after (A|B) finish, etc, >then the occam pseudocode (which I hope is self-explanatory) is:<br>
<br>I solved my problem in 2005. I wrote a synchronizer construct similar to what I previously posted. I believe the uthread module had counting semaphores. I make the assumption that tasklets terminate soon after they join. This keeps the code simple. Under the hood, only one, not number of children + 1 channels, are used.<br>
<br>That said, I think we are going around in circles....<br><br>I think Jeff Senn is right in that most Stackless users have a similar philosophical approach - that is if you want a new construct - roll your own in a module, rather than add to Stackless. Again, I believe channels are a very very powerful building block. However channels by themselves can be a very blunt instrument for complex tasks.<br>
<br>In regard to networking, I think the anarchical approach has worked. Some Stackless users like stacklessSocket module with LibEvent. I like using Twisted (and Twisted could be used with LibEvent).<br><br>Since I believe this thread originally began with asynchronous I/O, regardless of technique, there are basic gotchas. Perhaps if we could all agree on the basic gotchas, this knowledge could be modelled with PyPy and if it works, be placed in Stackless Python.<br>
<br>Cheers,<br>Andrew<br><br><br><br><br>--- On Wed, 10/22/08, Larry Dickson <<a href="mailto:ldickson@cuttedge.com">ldickson@cuttedge.com</a>> wrote:<br><br>> From: Larry Dickson <<a href="mailto:ldickson@cuttedge.com">ldickson@cuttedge.com</a>><br>
> Subject: Re: [Stackless] Stackless based replacement<br>> To: "Andrew Francis" <<a href="mailto:andrewfr_ice@yahoo.com">andrewfr_ice@yahoo.com</a>><br>> Cc: <a href="mailto:stackless@stackless.com">stackless@stackless.com</a><br>
> Date: Wednesday, October 22, 2008, 7:21 AM<br>> Hi Andrew,<br>><br>> What is needed is the PAR construct: I do not believe any<br>> combination of<br>> channels can do the same exactly. If C starts after (A|B)<br>
> finish, etc, then<br>> the occam pseudocode (which I hope is self-explanatory) is:<br>><br>> SEQ<br>> PAR<br>> A<br>> B<br>> --END PAR<br>> C<br>> PAR<br>> D<br>> E<br>
> --END PAR<br>> F<br>><br>> If you want to start them all at the same time it would<br>> require some<br>> channels to make them end in order:<br>><br>> PAR<br>> SEQ<br>> PAR<br>> SEQ<br>
> PAR<br>> A<br>> B<br>> --END PAR<br>> communicate to C<br>> C (communicate from AB)<br>> --END PAR<br>> communicate to D<br>> communicate to E<br>
> SEQ<br>> PAR<br>> D (communicate from ABC)<br>> E (communicate from ABC)<br>> --END PAR<br>> communicate to F<br>> F (communicate from DE)<br>> --END PAR<br>><br>> A PAR requires the parent store two words (its --END PAR<br>
> resumption<br>> instruction address and n-1 where n is the number of<br>> children) and start<br>> (i.e. schedule) n-1 child tasklets (and branch to the<br>> n-th). Each child must<br>> terminate with an 'endp' which checks the second<br>
> word. If it is >0 it<br>> decrements it and abandons its instruction stream. If it is<br>> 0 it branches to<br>> the parent's resumption address.<br>><br>> Larry<br>><br>> On 10/22/08, Andrew Francis <<a href="mailto:andrewfr_ice@yahoo.com">andrewfr_ice@yahoo.com</a>><br>
> wrote:<br>> ><br>> > Larry:<br>> ><br>> > >Do you mean C starts after (A|B) finish, or they<br>> all start together, or<br>> > >..?<br>> ><br>> > Why did I write that in 2005?<br>
> ><br>> > Yes C should start after A AND B finish. However the<br>> way the code is<br>> > written, tasklets actually start before they block on<br>> channels.<br>> ><br>> > The point of that example was it was *very* easy to<br>
> create a deadlock<br>> > scenario with a relatively simple precedent graph<br>> implemented with just<br>> > channels.<br>> ><br>> > Cheers,<br>> > Andrew<br>> ><br>> ><br>
> ><br>> ><br>> ><br>> ><br>> > --- On Tue, 10/21/08, Larry Dickson<br>> <<a href="mailto:ldickson@cuttedge.com">ldickson@cuttedge.com</a>> wrote:<br>> ><br>> > > From: Larry Dickson <<a href="mailto:ldickson@cuttedge.com">ldickson@cuttedge.com</a>><br>
> > > Subject: Re: [Stackless] Stackless based<br>> replacement<br>> > > To: <a href="mailto:andrewfr_ice@yahoo.com">andrewfr_ice@yahoo.com</a><br>> > > Cc: <a href="mailto:stackless@stackless.com">stackless@stackless.com</a><br>
> > > Date: Tuesday, October 21, 2008, 9:46 AM<br>> > > Hi Andrew,<br>> > ><br>> > > I read your 2005 note, and I do not understand<br>> > ><br>> > > >I expect the following execution trace<br>
> > > ><br>> > > >(A | B) C (D | E) F<br>> > > ><br>> > > >|* - means processes can execute in parallel.<br>> > > *><br>> > > >It is okay to see B finish before A. However<br>
> it is<br>> > > >wrong to see C finish before B and A finish.<br>> > ><br>> > > Do you mean C starts after (A|B) finish, or they<br>> all start<br>> > > together, or ..?<br>> > ><br>
> > > Larry<br>> > ><br>> > > On 10/21/08, Andrew Francis<br>> <<a href="mailto:andrewfr_ice@yahoo.com">andrewfr_ice@yahoo.com</a>><br>> > > wrote:<br>> > > ><br>> > > > Hi Larry:<br>
> > > ><br>> > > > > We seem to have different ideas of what<br>> is<br>> > > simple. You<br>> > > > > propose exceptions, waits, signals,<br>> barriers,<br>> > > re-initialization,<br>
> > > > > and presumably global signal values.<br>> This in my<br>> > > opinion is a whole<br>> > > > >Italian restaurant of spaghetti, and it<br>> sounds<br>> > > intrinsically global, >which<br>
> > > > is poison to maintainable multiprocessing in<br>> my<br>> > > experience.<br>> > > ><br>> > > > This is what I had in mind. A sketch.<br>> > > ><br>> > > > def producer(synchronizer):<br>
> > > > try:<br>> > > > # do some computation<br>> > > > synchronizer.signal(result)<br>> > > > except Signalled, data<br>> > > > # oops the consumer has moved on....<br>
> maybe<br>> > > > # I should gracefully terminate.....<br>> > > ><br>> > > ><br>> > > > def consumer(synchronizer):<br>> > > > output = synchronizer.wait()<br>
> > > > # okay, let us do some stuff with the<br>> output<br>> > > ><br>> > > > synchronizer =<br>> Synchronizer(numberOfProducers)<br>> > > > stackless.tasklet(consumer)(synchronizer)<br>
> > > > for .... :<br>> > > > stackless.tasklet(producer)(synchronizer)<br>> > > ><br>> > > > Most of the effort is in defining the right<br>> > > behaviour.....<br>
> > > ><br>> > > > Once again, my experiences are when you<br>> naively use<br>> > > channels, it is easy to<br>> > > > get in trouble. A construct like<br>> receive_first()<br>
> > > looks difficult to<br>> > > > implement, in comparison to a synchronizer.<br>> > > ><br>> > > > Here is a thread from December 2005 (2005!)<br>> > > ><br>> > > ><br>
> > ><br>> <a href="http://www.stackless.com/pipermail/stackless/2005-December/000290.html">http://www.stackless.com/pipermail/stackless/2005-December/000290.html</a><br>> > > ><br>> > > > Cheers,<br>
> > > > Andrew<br>> > > ><br>> > > ><br>> > > ><br>> > > ><br>> > > ><br>> > > ><br>> > > ><br>> > > ><br>> > > ><br>
> ><br>> ><br>> ><br>> > __________________________________________________<br>> > Do You Yahoo!?<br>> > Tired of spam? Yahoo! Mail has the best spam<br>> protection around<br>> > <a href="http://mail.yahoo.com">http://mail.yahoo.com</a><br>
> ><br><br><br><br></blockquote></div><br>