On Wed, Sep 4, 2013 at 7:05 AM, Andrew Francis <[email protected]> wrote: > It is my belief that synchronous first order channels (that is the channels > themselves can be sent in messages) with buffering provides a simple yet > powerful concurrency model. I strongly believe that we can hide asynchrony > from the application programmer.
I am not sure that is a good idea. The application programmer needs to know exactly where the asynchrony is, so that he can deal with the fallout. Just because Stackless can wrap that asynchrony in a readable and painless way compared to the alternatives, does nothing about the fact that dependent state may change under the code while the asynchrony is going on. To me, hiding the asynchrony is less important than making an easy to use interface. > Until now, I have felt that folks on the Stackless mailing list have thrown > the baby out with the bathwater when I introduced select and join. It > doesn't help that I was defensive at the time, haven't released a copy of > the code (it is messy with few tests) or for that matter given a good > presentation. I've always found it too close to CSP, and too complicated and arcane. With stackless currently, as Christian made it, you can write straightforward readable code. I just can't see any code that comes into contact with select and join being as readable. > Right now I am toying with a new stackless.select (or stackless.alt, the > name 'select' seems to confuse folks) No Andrew, no. :-) alt is terrible, it means nothing. I don't think that's ever been the problem. > operations = [(chan1, RECV), (chan2, RECV), (cha3, SEND, 10), (ch_timeout, > RECV)] > (index, value) = stackless.select(operations) You don't think this is too complicated for everyday use? Look, I'm not trying to make you defensive again. I just want a straightforward and readable solution. It may be that Christian made the right call when he made Stackless and ditched all the select and join aspects of CSP, simply because it can never be a good fit except at too big a cost. Cheers, Richard. _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
