This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients YoSTEALTH, eric.snow, gregory.p.smith, josh.r, lisroach, ncoghlan, ned.deily, pablogsal, pitrou, pmpp, rhettinger, serhiy.storchaka, yselivanov
Date 2018-02-05.02:35:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1517798103.16.0.467229070634.issue31356@psf.upfronthosting.co.za>
In-reply-to
Content
If I recall the discussion correctly, it was:

1. That this was worth doing precisely because the naive approach is likely to be broken in the presence of multiple threads;
2. It was only worth doing either as a true global disable that accounted for multi-threading (e.g. backed by a counted semaphore or the functional equivalent), or else by making gc enable/disable status have a thread local toggle in addition to the global one (so the context manager can ensure "GC is off *in this thread*, regardless of the global status").

Either of those two options requires changes to the main GC machinery though, as otherwise you basically *can't* write a correct context manager for this use case, since a direct call to gc.enable() in another thread would always be problematic.
History
Date User Action Args
2018-02-05 02:35:03ncoghlansetrecipients: + ncoghlan, rhettinger, gregory.p.smith, pitrou, ned.deily, pmpp, eric.snow, serhiy.storchaka, yselivanov, josh.r, YoSTEALTH, lisroach, pablogsal
2018-02-05 02:35:03ncoghlansetmessageid: <1517798103.16.0.467229070634.issue31356@psf.upfronthosting.co.za>
2018-02-05 02:35:03ncoghlanlinkissue31356 messages
2018-02-05 02:35:01ncoghlancreate