<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>Hi  Richard and Folks:</span></div><div><br></div><div style="font-family: 'times new roman', 'new york', times, serif; font-size: 12pt;"><div style="font-family: 'times new roman', 'new york', times, serif; font-size: 12pt;"><div class="y_msg_container">----------------------------------------------------------------------<br><br>Message: 1<br>Date: Wed, 4 Sep 2013 09:27:33 +1200<br>From: Richard Tew <<a ymailto="mailto:richard.m.tew@gmail.com" href="mailto:richard.m.tew@gmail.com">richard.m.tew@gmail.com</a>><br>To: Andrew Francis <<a ymailto="mailto:andrewfr_ice@yahoo.com" href="mailto:andrewfr_ice@yahoo.com">andrewfr_ice@yahoo.com</a>><br>Cc: "<a ymailto="mailto:stackless@stackless.com" href="mailto:stackless@stackless.com">stackless@stackless.com</a>" <<a
 ymailto="mailto:stackless@stackless.com" href="mailto:stackless@stackless.com">stackless@stackless.com</a>><br>Subject: Re: [Stackless] CSPish Re:  stacklesslib.async<br>Message-ID:<br>    <CAN=X-TGTiKNj2u+8D4xOzv=<a ymailto="mailto:ZvZrtKzDmnbHE-4LfTqMcQ-szDw@mail.gmail.com" href="mailto:ZvZrtKzDmnbHE-4LfTqMcQ-szDw@mail.gmail.com">ZvZrtKzDmnbHE-4LfTqMcQ-szDw@mail.gmail.com</a>><br>Content-Type: text/plain; charset=ISO-8859-1<br><br>On Wed, Sep 4, 2013 at 7:05 AM, Andrew Francis <<a ymailto="mailto:andrewfr_ice@yahoo.com" href="mailto:andrewfr_ice@yahoo.com">andrewfr_ice@yahoo.com</a>> wrote:<br><br></div><div class="y_msg_container">AF> It is my belief that synchronous first order channels (that is the channels<br>AF> themselves can be sent in messages) with buffering provides a simple yet<br>AF> powerful concurrency model. I strongly believe that we can hide asynchrony<br>AF> from the application
 programmer.<br><br>>I am not sure that is a good idea.  The application programmer needs<br>>to know exactly where the asynchrony is, so that he can deal with the<br>>fallout.</div><div class="y_msg_container"><br></div><div class="y_msg_container">Why? I think the writer of the otherwise asynchronous routine should return an exception or some other message on a channel.</div><div class="y_msg_container"><br></div><div class="y_msg_container">>  Just because Stackless can wrap that asynchrony in a<br>>readable and painless way compared to the alternatives, does nothing<br>>about the fact that dependent state may change under the code while<br>>the asynchrony is going on.  To me, hiding the asynchrony is less<br>>important than making an easy to use interface.<br><br>I don't quite follow. Are you referring to race conditions that can occur because Stackless channels are are passing objects by reference? I can also
 see problems when one directly maps low-level sockets onto channels.<br><br>>I've always found it too close to CSP, and too complicated and arcane.<br>>With stackless currently, as Christian made it, you can write<br>>straightforward readable code.</div><div class="y_msg_container"><br></div><div class="y_msg_container">However to get the behaviour of a select or a join, one has to write a lot of code that partly emulates those functions. Yes, my version of select is more complex than the current Stackless methods. However it was designed to do things right and efficiently (whether it actually does so is a different story). </div><div class="y_msg_container"><br></div><div class="y_msg_container">AF> Right now I am toying with a new stackless.select (or stackless.alt, the<br>AF> name 'select' seems to confuse folks)</div><div class="y_msg_container"><br>>No Andrew, no. :-)  alt is terrible, it means nothing.  I don't
 think<br>>that's ever been the problem.<br><br>Fair enough. I was heading back to alt (CSP alternative) that is used in Limbo. I found that folks confused select with the UNIX select function. <br><br>AF> operations = [(chan1, RECV),  (chan2, RECV), (cha3, SEND, 10), </div><div class="y_msg_container">AF>                       (ch_timeout, RECV)]<br>AF> (index, value) = stackless.select(operations)<br><br>>You don't think this is too complicated for everyday use?</div><div class="y_msg_container"><br></div><div class="y_msg_container">Is this more complicated than say the API for Python's implementation of UNIX select? </div><div class="y_msg_container"><br></div><div class="y_msg_container">I guess I could simplify the API a bit to :</div><div class="y_msg_container"><br>operations = [chan1.receive,  chan2.receive, (cha3.send, 10),
 ch_timeout.receive]</div><div class="y_msg_container">(index, value) = stackless.select(operations)<br><br>Does this improve things?<br><br><span style="font-size: 12pt;">>Look, I'm not trying to make you defensive again. </span></div><div class="y_msg_container"><span style="font-size: 12pt;"><br></span></div><div class="y_msg_container"><span style="font-size: 12pt;">You are bringing up good arguments. </span></div><div class="y_msg_container"><span style="font-size: 12pt;"><br></span></div><div class="y_msg_container"><span style="font-size: 12pt;">> I just want a </span>straightforward and readable solution.  It may be that Christian made<br>>the right call when he made Stackless and ditched all the select and<br>>join aspects of CSP, simply because it can never be a good fit except<br>>at too big a cost.<br></div><div class="y_msg_container"><br></div><div class="y_msg_container">Let's treat select and join
 separately.</div><div class="y_msg_container"><br></div><div class="y_msg_container">Historically select/alt is an intrinsic part of the Bell Labs channel model. In the Plan9 channel implementation, channel send/receive are really selects with one operation. Once I do a rewrite of my select implementation, I can run tests to see how much of a performance hit a Stackless programme takes. </div><div class="y_msg_container"><br></div><div class="y_msg_container">On the other hand, my implementation of join patterns is taking liberties with the Polyphonic C# implementation of Join Patterns. I just happened to see a way of extending the Plan9 channel select algorithm to accommodate join. It is very experimental. So far, I can implements problems I have encountered in papers. Still my jury is out on whether I have captured the expressive power of Polyphonic C# Still I think something like:</div><div class="y_msg_container"><br></div><div
 class="y_msg_container"># block until results are received from all the channels in the list</div><div class="y_msg_container">result =  stackless.join([c1, c2, ....])</div><div class="y_msg_container">or</div><div class="y_msg_container">result = stackless.waitAll([c1, c2, ...])      </div><div class="y_msg_container"><br></div><div class="y_msg_container">is useful and is much more in keeping with the Stackless Python works. </div><div class="y_msg_container"><br></div><div class="y_msg_container">In my mind, I have this select method that can handle disjunctions of conjunctions of channel operations being used to provide the heavy lifting. Yes one can expose this rather complex method to the application programmer. However we can use syntactic sugar to simplify things.</div><div class="y_msg_container"><br></div><div class="y_msg_container">Again, I think PyPy makes a great testing ground for these ideas ....</div><div
 class="y_msg_container"><span style="background-color: transparent;"><br></span></div><div class="y_msg_container">Cheers,</div><div class="y_msg_container">Andrew</div><div class="y_msg_container"><br></div><div class="y_msg_container"><br></div><div class="y_msg_container"><br></div><div class="y_msg_container"><br></div> </div> </div>  </div></body></html>