[Stackless] Google's new Go programming language

Andrew Francis andrewfr_ice at yahoo.com
Mon Nov 23 18:13:27 CET 2009

Hello Richard:

Message: 4
Date: Mon, 16 Nov 2009 07:49:49 +1300
From: Richard Tew <richard.m.tew at gmail.com>
To: Andrew Dalke <dalke at dalkescientific.com>
Cc: Stackless mailing list <stackless at stackless.com>
Subject: Re: [Stackless] Google's new Go programming language
    <952d92df0911151049k50969be8o3807b72f380f55a0 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

>I pictured it having an interface like:
>while True:
>    selected_channel = select(quit_channel, request_channel)
>    if selected_channel is quit_channel:
>        return
>    elif selected_channel is request_channel:

This is essentially how I would write it.  I would provide a
list of channels and return a list of channels that are ready. For efficiency, I would provide an additional value, hint, to prevent
the scheduler from tearing-down the structure when select returns.

readyList = select([channels], hint = True)

but for a start I would simply the interface to return a single channel.

>We could accomplish this by making channel subclasses perhaps that
>allow something like 'select' to intercept operations.  

I have been studying PyPy Stackless.py. For efficiency, I believe you 
want to put changes into the scheduler. If you want to approximate Go's 
select (which I don't), you need a way to prevent the scheduler from carrying out a channel operation but schedule the tasklet in question.
Channel preferences complicate things.

> it might be argued that an operator like this would
>allow more readable code as handling of separate blocking actions
>could be distilled into one function/tasklet.

>But again, I cannot think of any use cases offhand that would benefit
>from it. 

Event handlers are the first use case that comes to my mind. I write
stuff that is tantamount to:

while True:
    ch = select([list of channels])
    if ch == ch[0]:
       request = ch[0].receive()
    if ch == ch[1]:

Right now, the code is a tasklet per channel, each tasklet in a loop
blocked on the channel until something happens.

I believe the resulting code logic would be easier to write with a
select function and/or a select language feature.

> As it stands, I see Stackless being a basic framework of
>low-level functionality.  Solutions like 'select' are perhaps better
>coded to address actual needs in custom frameworks built on the
>low-level framework that is Stackless.

I understand your minimalist approach towards Stackless. However I think
Stackless can evolve only so far without actual changes to the scheduler. Priorities involved a change to the scheduler. Again, I believe PyPy provides an opportunity to prototype changes in a safe and fast way.



More information about the Stackless mailing list