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. _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
