<html><body bgcolor="#FFFFFF"><div>Just a quick note, as I'm moving right now and inactive for another month, and had no time to look at the code at all:</div><div><br></div><div>The survival of an interface goes with its simplicity and usability. If it fails that, then Stackless is not improved: having a hard-to-understand feature or no feature at all makes little difference. The academic achievement is fine for the scientist, but that will not be enough reason to add the feature. </div><div><br></div><div>Richard had a problem to understand the proposed interface, being much more that an experienced user. I would take that as a serious indicator that the interface must change its whole approach. There need to be a direct, simple as possible way to see the benefit of the feature, and how to use it in the most common scenarios. Every more detailed sub-interface may come after that, after the hurdle of making the user interested is taken. </div><div><br></div><div>Just my 2 cents, after I made this mistake myself way too often. </div><div><br></div><div>Cheers - chris<br><br>Sent from my iPhone</div><div><br>On Aug 25, 2011, at 18:08, Andrew Francis <<a href="mailto:andrewfr_ice@yahoo.com">andrewfr_ice@yahoo.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><div style="color:#000; background-color:#fff; font-family:Courier New, courier, monaco, monospace, sans-serif;font-size:12pt"><span style="font-family: times new roman,new york,times,serif;">Hi Richard:</span><br style="font-family: times new roman,new york,times,serif;"><br style="font-family: times new roman,new york,times,serif;"><span style="font-family: times new roman,new york,times,serif;">Thanks for the input. Yahoo is a pain in the butt when it comes to replying.</span><br><br><div style="font-family: Courier New,courier,monaco,monospace,sans-serif; font-size: 12pt;"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">>First the superficial stuff.  Dining philosophers is boring and<br>>academic.  It wasn't interesting to me in university, it isn't now,<br>>and its lack of usefulness hides the usefulness of whatever implements<br>>it. <br><br>Dining philosophers is academic. However
 I hardly think it is boring. Dining philosophers like so many computer problems are contrived on purpose. However the techniques to solve them are extremely applicable. On a side note, I am going through "The Little Book of Semaphores" and looking at the examples. <br><br>As for join patterns. For me join patterns hint to a more clutter-free and declarative style of concurrency. At its heart is the ability to atomically perform transactions. <br><br>I am still learning.....<br><br>>Next your join patterns and select.  When I read the code I don't<br>>understand it.  I think that there has to be a simpler interface than<br>>arcane terms like "joinPattern", "JoinReceiveChanop" and<br>>"receiveCase".  <br><br>As I stated in the original post, I am still working on the API. When complete, you will not see JoinReceiveChanop: it is an implementation detail. Nor will you see select(). This is again an interesting implementation
 detail. I extended the algorithms of Pike/Cox to support a limited form of join patterns. So in a scene, the same algorithm should work in Go (albeit with a big performance hit).  What the example will eventually look more like:<br><br><font size="2"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">def thinker(name, thinking, left, right):</span><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;"></span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">    while True:</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">       waitTime = random.randint(thinking[0], thinking[1])</span><br style="font-family: Courier
 New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">       print name, "thinking for ", waitTime, "time units"</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">       tick(waitTime)</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">       print name, "ready to eat"</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">       result = stackless.join().addPattern([left,right]).do()</span><br style="font-family: Courier
 New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">       for p in result:</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"><span style="font-family: Courier New,courier,monaco,monospace,sans-serif;">           print p.value, " relinquished chopstick ", p.channel.label</span><br style="font-family: Courier New,courier,monaco,monospace,sans-serif;"></font><br>Does this make more sense?<br><br>Again, I am working on the API. Heck I am still working on the implementation. Amongst other things I need to write more tests to ensure stuff is really working.<br><br>>However, I think I would need that practical example<br>>where this is useful before I could suggest something better. <br><br>I will work on more practical examples. I can show how to use join patterns to impose a
 logical ordering on tasklets. Or how to implement the foreach statement in WS-BPEL. Or to do M out of N choices: i.e., send requests for quotes to ten contractors (imagine these being RESTful web services) and block until one gets   a quorum of seven... or a timeout. Or replace contractor web services with sensor interfaces, say something a Green Goose tagged internet-of-things object would generate.  <br><br>That said, I am really interested in how much of a performance hit does the Stackless.py prototype take implementing join and select. I don't think the extra power is worthwhile to make it a general feature if it imposes a big performance cost on simple things. Quite frankly, I think a stackless with select and join will be in a custom tailored module running under PyPy. Once genlets are working, this would be the way to go.<br><br>>expect that the only way to make a straightforward and easy to use<br>>interface would be if the
 language facilitated it, and as you are<br>>using pypy I believe, that's actually a possibility.<br><br>Originally this was the opinion of my friend Kevin (whom immensely helped me with select) and myself. However after actually writing examples, I had come not to share this opinion. Moreover I regularly read the Go mailing list. I have seen how difficult it is to write examples with a dynamic number of channels with a fixed select language feature. And to wait on multiple goroutines, mutexes are used.  <br><br>On the other hand,  I have seen the object based work that Microsoft has done with Polyphonic C# and this seems to be a model more suited for Stackless. <br><br>As you have pointed out, the key is to write more practical examples. Also if people use the experimental features then we can craft a better API. I will be the first to admit that without language support, the API can be tricky. So let me do some more work and get a new
 implementation into the stackless repository.<br><br>>Anyway hope this is of some help,<br><br>Yes it is!<br><br>Cheers,<br>Andrew<br></div></div></div></div></blockquote></body></html>