On Mar 4, 2005, at 23:55, Brett C. wrote:
Evan uploaded the newest version (@ http://www.python.org/sf/1123430)
and he says it is complete.
I should point out (very late! It's been a busy couple of weeks) that I
fully expect that there may be some issues with the patch that will
arise when it
Brett C. wrote:
Assuming a code review says the patch is sane, do we want to go with
this garbage collection change? From past discussions I don't remember
a consensus on acceptance or rejection, just lots of discussion about
ripping out the hacks to allow freeing memory w/o holding the GIL (I
Evan Jones wrote:
Sorry for taking so long to get back to this thread, it has been one of
those weeks for me.
On Feb 16, 2005, at 2:50, Martin v. Löwis wrote:
Evan then understood the feature, and made it possible.
This is very true: it was a very useful exercise.
I can personally accept
Sorry for taking so long to get back to this thread, it has been one of
those weeks for me.
On Feb 16, 2005, at 2:50, Martin v. Löwis wrote:
Evan then understood the feature, and made it possible.
This is very true: it was a very useful exercise.
I can personally accept breaking the code that
[Evan Jones]
After I finally understood what thread-safety guarantees the Python
memory allocator needs to provide, I went and did some hard thinking
about the code this afternoon. I believe that my modifications provide
the same guarantees that the original version did. I do need to declare
[Tim Peters]
As I said before, I don't think we need to support this any more.
More, I think we should not -- the support code is excruciatingly
subtle, it wasted plenty of your time trying to keep it working, and
if we keep it in it's going to continue to waste time over the coming
years
Tim Peters wrote:
I'm not certain it is acceptable to make this assumption. Why is it
not possible to use the same approach that was previously used (i.e.
leak the arenas array)?
Do you have something else in mind? I'll talk with Martin about it if
he still wants to. Martin, this
