[issue41545] gc API requiring matching number of gc.disable - gc.enable calls
Yonatan Goldschmidt
report at bugs.python.org
Fri Aug 14 04:04:36 EDT 2020
Yonatan Goldschmidt <yon.goldschmidt at gmail.com> added the comment:
> If this race condition is a bug in gc, then we should fix that.
> If it is a bug in your code, surely you should fix that rather than disable gc.
It's neither: it is something related to the combination of some 3rd party libraries I'm using (if you're interested, I have described it here: https://github.com/paramiko/paramiko/issues/1634).
> Either way, I don't think we should complicate the gc iterface by adding a second way to enable and disable the cyclic gc.
I see what you're saying. I wasn't thinking of of this idea as complicating it, I had in mind existing interfaces which have these 2 sets of functions (for example, Linux's local_irq_enable/disable and local_irq_save/restore).
Another approach, only modifying the existing API in a compatible way, will be as follows:
--- a/Modules/gcmodule.c
+++ b/Modules/gcmodule.c
@@ -1489,9 +1489,10 @@ static PyObject *
gc_disable_impl(PyObject *module)
/*[clinic end generated code: output=97d1030f7aa9d279 input=8c2e5a14e800d83b]*/
{
+ int was_enabled = gcstate->enabled
GCState *gcstate = get_gc_state();
gcstate->enabled = 0;
- Py_RETURN_NONE;
+ return was_enabled ? (Py_INCREF(Py_True), Py_True) : (Py_INCREF(Py_False), Py_False);
}
Then I can write code this way:
foo():
disabled = gc.disable()
....
if disabled:
gc.enable()
It can be taken ahead to change `gc.enable()` to `gc.enable(disabled=True)` so I can just call it as `gc.enable(disabled)`:
foo():
disabled = gc.disable()
....
gc.enable(disabled)
----------
_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41545>
_______________________________________
More information about the Python-bugs-list
mailing list