CPython 2.7: Weakset data changing size during internal iteration

[Temia Eszteri]

On 03 Jun 2012 16:20:11 GMT, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:

>And should I have known this from your initial post?

I did discuss the matter with Terry Reedy, actually, but I guess since
the newsgroup-to-mailing list mirror is one-way, there's no actual way
you could've known. :/ Sigh, another problem out of my hands to deal
with. I do apologize for the snippy attitude, if it means anything.

>Frankly, I still doubt that your analysis of the problem is correct:
>
>    [quote]
>    Problem is that for certain high-frequency operations, it 
>    seems there's too much data going in and out for it to handle
>    [end quote]
>
>
>I still can't see any way for this bug to occur due to "too much data", 
>as you suggest, or in the absence of one thread modifying the set while 
>another is iterating over it. But I could be wrong.

Well, in this case, I'd consider it more reasonable to look at it from
a different angle, but it was rather poorly-phrased at the beginning.
When you've got dozens of objects being garbage-collected from the set
every 16 miliseconds or so though, that's certainly high-frequency
enough to trigger the bug, is it not?

>In any case, it appears that this bug has already been reported and fixed:
>
>http://bugs.python.org/issue14159
>
>Consider updating to the latest bug fix of 2.7.

Alas, I'm already on the latest official release, which doesn't have
the patch yet. I'll just apply it manually.

Though now I'm now curious about how regular sets get their truth
value, since weaksets internally performing a length check every time
a texture was being referenced or de-referenced, for simple lack of a
faster explicit __bool__ value, is going to be rather costly when
things'll be flying around and out of the screen area in large
quantities. Hoo boy.

~Temia
-- 
The amazing programming device: fuelled entirely by coffee, it codes while
awake and tests while asleep!