[issue41545] gc API requiring matching number of gc.disable - gc.enable calls

Yonatan Goldschmidt added the comment: Dennis, you're right. I guess I missed it when I previously searched for matching issues. https://bugs.python.org/issue31356 indeed solves my problem. Closing this as a duplicate. -- resolution: -> duplicate stage: -> resolved status: open ->

[issue41545] gc API requiring matching number of gc.disable - gc.enable calls

Dennis Sweeney added the comment: It looks like this was a duplicate of https://bugs.python.org/issue31356 -- ___ Python tracker ___

[issue41545] gc API requiring matching number of gc.disable - gc.enable calls

Yonatan Goldschmidt added the comment: Hmm... I didn't think of overlapping lock periods. You are right, Dennis, a counter must be managed. -- ___ Python tracker ___

[issue41545] gc API requiring matching number of gc.disable - gc.enable calls

Dennis Sweeney added the comment: FWIW I forgot the gc.disable() line in the contextmanager, but what I said still applies. -- ___ Python tracker ___

[issue41545] gc API requiring matching number of gc.disable - gc.enable calls

Dennis Sweeney added the comment: The save-a-boolean-for-each-context-manager approach has an issue if used with concurrent generators, where the lifetimes of two generator objects might be overlapping but not completely nested, as shown below. The same issue should arise when using

[issue41545] gc API requiring matching number of gc.disable - gc.enable calls

Yonatan Goldschmidt 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

[issue41545] gc API requiring matching number of gc.disable - gc.enable calls

Irit Katriel added the comment: There is also gc.isenabled(), so couldn't you check that before disabling and remember whether you needed to disable or not? -- nosy: +iritkatriel ___ Python tracker

[issue41545] gc API requiring matching number of gc.disable - gc.enable calls

Dennis Sweeney 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. Usage: from no_gc import no_gc with no_gc(): # collection disabled with no_gc(): # collection is

[issue41545] gc API requiring matching number of gc.disable - gc.enable calls

Ammar Askar added the comment: > 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. I don't think this API makes

[issue41545] gc API requiring matching number of gc.disable - gc.enable calls

Yonatan Goldschmidt 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

[issue41545] gc API requiring matching number of gc.disable - gc.enable calls

Steven D'Aprano added the comment: > I wrap a function's logic with `gc.disable()` to prevent GC from triggering > some race condition. 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. Either

[issue41545] gc API requiring matching number of gc.disable - gc.enable calls

New submission from Yonatan Goldschmidt : 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: