[Stackless] 2.5b3 has been merged into SVN trunk

[Richard Tew]

Hi,

I have just taken the liberty of using an hour of work time to merge in
the 2.5b3 changes into the Stackless SVN trunk.  Happily we have
no more known bugs than before the merge, but sadly we have no less
known bugs.

http://svn.python.org/projects/stackless/trunk/

Things people can do to help out:

- Compile it and make sure it compiles properly on your platform.  I
  have only compiled it on Windows with Visual Studio 2003.  I see
  there were changes merged into the configure scripts, these have
  been problematic after merges in the past, so it would be good to
  get feedback that they work fine.  Both running the configure script
  and deleting it and building it from the configure.in script would be
  good.

- Run the Python regression tests after compiling it.  On Windows I do:

    PCBuild\python_d.exe Lib\test\regrtest.py

- Run the Stackless unittests.  I find that I have to set the current
  directory to the unittest directory (Stackless/unittests) and run
  the 'runAll.py' script there.  On Windows I do:

    cd Stackless\unittests
    ..\..\PCBuild\python_d.exe runAll.py

The known bugs at this time are:

- When the taskspeed.py test is run in release mode, channel / tasklet
  garbage collection causes a tasklet that has only ever been soft
  switched into, to be hard switched into so that the tasklet exit
  exception can be raised on it.

  While I have debugged this, I do not have an idea of the proper fix
  for it yet.

- Michael Brenner's bug report, which we have a patch for:

  http://www.stackless.com/pipermail/stackless/2006-July/001807.html

  This is where a tasklet is scheduled with tasklet exit to kill it, but
  the natural behaviour of the scheduler then schedules the next tasklet
  which conflicts with the main tasklet which after garbage collection
  is killing off all the tasklets in a loop.

  With the time that has passed since this patch was created, I am now
  fairly confident that it is as correct a fix as we can have, without some
  better support in Stackless for enforcing that a tasklet once scheduled
  always returns back to the calling tasklet (or at least the main tasklet).
  My plan is to get a small reproducibility case and to add this to the
  stackless tests, then check this in, and the patch.

  This has not been checked into the 2.4.3 branch yet either.

Richard.

_______________________________________________
Stackless mailing list
Stackless at stackless.com
http://www.stackless.com/mailman/listinfo/stackless