[Stackless] CSPish Re: stacklesslib.async

[Richard Tew]

On Wed, Sep 4, 2013 at 7:05 AM, Andrew Francis <andrewfr_ice at yahoo.com> 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.