[Stackless] CSPish Re: stacklesslib.async

[Andrew Francis]

Hi  Richard and Folks:

----------------------------------------------------------------------

Message: 1
Date: Wed, 4 Sep 2013 09:27:33 +1200
From: Richard Tew <richard.m.tew at gmail.com>
To: Andrew Francis <andrewfr_ice at yahoo.com>
Cc: "stackless at stackless.com" <stackless at stackless.com>
Subject: Re: [Stackless] CSPish Re:  stacklesslib.async
Message-ID:
    <CAN=X-TGTiKNj2u+8D4xOzv=ZvZrtKzDmnbHE-4LfTqMcQ-szDw at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Sep 4, 2013 at 7:05 AM, Andrew Francis <andrewfr_ice at yahoo.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stackless.com/pipermail/stackless/attachments/20130904/c312c497/attachment.html>