[Stackless] Google's new Go programming language
andrewfr_ice at yahoo.com
Mon Nov 23 18:13:27 CET 2009
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:
> selected_channel = select(quit_channel, request_channel)
> if selected_channel is quit_channel:
> 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
Event handlers are the first use case that comes to my mind. I write
stuff that is tantamount to:
ch = select([list of channels])
if ch == ch:
request = ch.receive()
if ch == ch:
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