[Stackless] 2.5b3 has been merged into SVN trunk
senn at maya.com
Tue Aug 22 16:37:52 CEST 2006
On Aug 22, 2006, at 4:12 AM, Richard Tew wrote:
>> I believe the first fixes some problem we were having a few weeks
>> but don't remember what... It seems like safer code in any case.
The first one prevented an infinite recursion in tasklet destruction
(clear --> kill --> clear...) which happened during the bug
which is now gone...(I think it's the first one that "went away"
with the core python changes) so I'm not sure how to reproduce. I'm not
sure it fixed the bug, but it at least made it clear (when debugging)
where the problem was... not vital in any case (as long as that bug
doesn't come back :-) )
>> The second allows running the scheduler from other than the first
>> (I don't really see any problem with this. I.e. to me, the check
>> overly conservative)
> Can you provide reproducibility cases for both of these? I am
> about checking in fixes which I do not understand. And in any case,
> I would like where possible (if there are reproducibility cases) to
> add them
> to the unittests at the same time. If you could separate the fixes
> incorporate the unittests that would be even better :)
For the second, I'm not sure what you want me to reproduce. :)
It is essentially loosening a constraint that only allowed stackless.run
to be called from the first(main) thread. I have an application where
I need to .run from another thread (since the first thread needs to be
dedicated to a OS event loop). I've tried it and it seems to work.
The restriction was not there in the 2.4.2 stackless. Seems to have
added in .3, and I'm not sure why.... perhaps someone (Christian?)
remembers? or are there old CVS logs somewhere we can look at?
If it was only added to be conservative I'd like to revert to
the 2.4.2 behavior... otherwise, if someone can demonstrate a problem,
I'm highly motivated to get it solved...
Stackless mailing list
Stackless at stackless.com
More information about the Stackless