Hi Richard and Folks:
----------------------------------------------------------------------
Message: 1
Date: Wed, 4 Sep 2013 09:27:33 +1200
From: Richard Tew <[email protected]>
To: Andrew Francis <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [Stackless] CSPish Re: stacklesslib.async
Message-ID:
<CAN=X-TGTiKNj2u+8D4xOzv=zvzrtkzdmnbhe-4lftqmcq-s...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Sep 4, 2013 at 7:05 AM, Andrew Francis <[email protected]> wrote:
AF> It is my belief that synchronous first order channels (that is the channels
AF> themselves can be sent in messages) with buffering provides a simple yet
AF> powerful concurrency model. I strongly believe that we can hide asynchrony
AF> 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.
Why? I think the writer of the otherwise asynchronous routine should return an
exception or some other message on a channel.
> 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.
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.
>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.
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).
AF> Right now I am toying with a new stackless.select (or stackless.alt, the
AF> 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.
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.
AF> operations = [(chan1, RECV), (chan2, RECV), (cha3, SEND, 10),
AF> (ch_timeout, RECV)]
AF> (index, value) = stackless.select(operations)
>You don't think this is too complicated for everyday use?
Is this more complicated than say the API for Python's implementation of UNIX
select?
I guess I could simplify the API a bit to :
operations = [chan1.receive, chan2.receive, (cha3.send, 10),
ch_timeout.receive]
(index, value) = stackless.select(operations)
Does this improve things?
>Look, I'm not trying to make you defensive again.
You are bringing up good arguments.
> 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.
Let's treat select and join separately.
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.
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:
# block until results are received from all the channels in the list
result = stackless.join([c1, c2, ....])
or
result = stackless.waitAll([c1, c2, ...])
is useful and is much more in keeping with the Stackless Python works.
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.
Again, I think PyPy makes a great testing ground for these ideas ....
Cheers,
Andrew
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
