[Stackless] Stackless Python 2.6

Richard Tew richard.m.tew at gmail.com
Thu Oct 2 22:39:16 CEST 2008


Hi,

I've released Stackless Python 2.6.  Here's a brief overview..

Getting Stackless Python 2.6
=====================

You can download tarballs, binaries and installers from here (the
latter two are PC only, MacOS build on the way):
http://www.stackless.com/download/

Information about SVN repository access can be found here:
http://www.stackless.com/svn/

Changes
=======

There were several bug fixes to the workings of Stackless Python since
the release of 2.5.2, in addition a new feature has been added.

New Features
--------------------

- A new parameter 'soft' can be passed to the running of the
scheduler.  This parameter alters how pre-emptive scheduling works.
At the moment, when you pass a 'timeout' value to the scheduler to get
it to schedule pre-emptively, it exits when a tasklet has not blocked
for that period of time.  This can however leave tasklets blocked in
unexpected places, as you would expect with pre-emptive scheduling.
When the 'soft' parameter is set to True, the scheduler will exit when
a tasklet which runs longer than the 'timeout' period blocks and
another tasklet would otherwise be scheduled.

    ...
    stackless.run(1000, soft=True)
    ...

- Extended C API for channel usage.

- MIPS processor hard switching support.

- Interthread locking has been improved.

Bug Fixes
---------------

- The 'zip' file Windows binary archive now includes the standard
include files and not just the additional Stackless ones.  There are
Stackless related modifications to the standard include files which
are needed if someone is to compile against a standard Python
installation which has had the Stackless binary archive extracted over
the top of it.

- Backwards compatibility breaking: The scheduler will no longer block
when it runs out of tasklets to schedule and there are other Python
threads running.  This was done to allow the scheduler to wait for
tasklets blocked on channels, so that it could run them when activity
on other threads awakened them.  If the old behaviour is desired, the
'threadblock' parameter can be passed to the scheduler to reenable it.
 This change was made to make the behaviour of the scheduler more
predictable.  Unless a user understood the old behaviour, it seemed
like the interpreter locked up when this was triggered.

    ...
    stackless.run(threadblock=True)
    ...

- Ensure that 'stackless.run' does not return strange out of place
values.  There were occasional unreproducible reports that people were
encountering this behaviour.  The scheduler should only return 'None'
or a reference to a tasklet which was interrupted, not leaked values
like strings.

- An old bug would leave a tasklet with no cstate under certain
circumstances.  This is no longer the case.

Cheers,
Richard.




More information about the Stackless mailing list