[New-bugs-announce] [issue41545] gc API requiring matching number of gc.disable - gc.enable calls
report at bugs.python.org
Thu Aug 13 19:52:21 EDT 2020
New submission from Yonatan Goldschmidt <yon.goldschmidt at gmail.com>:
I have a construct in my code where I wrap a function's logic with `gc.disable()` to prevent GC from triggering some race condition.
Today this construct got a bit more complicated, and another function had to use this "trick". Now there are 2 flows:
# bar calls foo, which also messes with the gc
I'd expected the GC to be truly enabled only on the second call to `enable()`, but apparently it's enabled on the first call :( Both `gc.enable()` and `gc.disable()` just write `1`/`0` to `gcstate->enabled`, respectively.
For the meantime I wrote a simple wrapper class to do this counting (finally calling `enable()` only when necessary).
Another option is for the code to check first "is GC enabled?" before disabling, and before enabling again, remember whether it really disabled it or not.
But I think those manual workarounds are more error prone, and it's easier to forget to use it them in all sites (compared to using the "right" API from the standard module), so I was considering if we can add an API that encapsulate this counting: an enable-disable pair that makes sure GC is only enabled back when the number of "enable" calls matches the number of "disable" calls.
components: Interpreter Core
nosy: Yonatan Goldschmidt
title: gc API requiring matching number of gc.disable - gc.enable calls
versions: Python 3.10
Python tracker <report at bugs.python.org>
More information about the New-bugs-announce