Yonatan Goldschmidt <yon.goldschm...@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 <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
