Hi Richard: Thanks for the input. Yahoo is a pain in the butt when it comes to replying.
>First the superficial stuff. Dining philosophers is boring and >academic. It wasn't interesting to me in university, it isn't now, >and its lack of usefulness hides the usefulness of whatever implements >it. 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. 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. I am still learning..... >Next your join patterns and select. When I read the code I don't >understand it. I think that there has to be a simpler interface than >arcane terms like "joinPattern", "JoinReceiveChanop" and >"receiveCase". 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: def thinker(name, thinking, left, right): while True: waitTime = random.randint(thinking[0], thinking[1]) print name, "thinking for ", waitTime, "time units" tick(waitTime) print name, "ready to eat" result = stackless.join().addPattern([left,right]).do() for p in result: print p.value, " relinquished chopstick ", p.channel.label Does this make more sense? 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. >However, I think I would need that practical example >where this is useful before I could suggest something better. 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. 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. >expect that the only way to make a straightforward and easy to use >interface would be if the language facilitated it, and as you are >using pypy I believe, that's actually a possibility. 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. 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. 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. >Anyway hope this is of some help, Yes it is! Cheers, Andrew
_______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
