New submission from Yonatan Goldschmidt <yon.goldschm...@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:
foo():
gc.disable()
....
gc.enable()
bar()
....
gc.disable()
...
# bar calls foo, which also messes with the gc
foo()
gc.disable()
...
gc.enable()
...
gc.enable()
...
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
messages: 375355
nosy: Yonatan Goldschmidt
priority: normal
severity: normal
status: open
title: gc API requiring matching number of gc.disable - gc.enable calls
type: enhancement
versions: Python 3.10
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue41545>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
