Yonatan Goldschmidt <[email protected]> added the comment:
> This is exactly the motivation for context managers, no? I attached no_gc.py,
> which works when nested and should additionally be thread-safe.
My solution was roughly the same (also a context manager, but a bit simplified
because I didn't need threading support so I didn't bother with locking).
> There is also gc.isenabled(), so couldn't you check that before disabling and
> remember whether you needed to disable or not?
Yes, but it must be protected like Dennis suggested, otherwise it can't be used
in a race-free way, for example this snippet is susceptible to a thread switch
between the `isenabled()` and `disable()` calls (so another thread could
meanwhile disable GC, and we retain a stale `was_enabled` result)
was_enabled = gc.isenabled()
gc.disable()
...
if was_enabled:
gc.enable()
My points in this issue are:
1. I think that such a safer API should be available in the standard library (I
don't want to find myself repeating this across different projects). I think
that wherever you find yourself using `gc.disable()` you should actually be
using a safer API (that takes into account multithreading & previous
invocations of `gc.disable()`)
2. A tiny change in `gc.enable()` (as I suggested in msg375376) can make it
substantially easier for the Python side to protect itself, because it will be
race-free without any locks.
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue41545>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
