CPython without a global interpreter lock
CPython without a global interpreter lock
Posted Aug 11, 2023 16:49 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)In reply to: CPython without a global interpreter lock by alkbyby
Parent article: CPython without a global interpreter lock
A lot of Python code out there depends on deterministic destruction for resource cleanup. It has always been a somewhat bad idea, but it IS the case right now.
Moving to a full GC will subtly break this code. For example, a sequence like this will work _most_ of the time on Windows:
If the GC is fast enough to immediately clean up the `fl` descriptor, then everything will work. But sometimes GC will not have time to run, and `os.unlink` will fail with a "file locked" error.
def do_something(name):
fl = open(name)
fl.read()
...
do_something("blah");
os.unlink("blah");
Posted Aug 11, 2023 22:04 UTC (Fri)
by khim (subscriber, #9252)
[Link] (1 responses)
Nope. It wouldn't. Or, raither: it may work on your system, but if you would try to give that code to someone then pretty soon your tracker would be overflowing with messages about how nothing works. Because AV software and “security” software (like this abomination) would keep your file around for a few seconds to “investigate” it. The only way to deal with it is to catch OSError and repeat the operation after some time (with exponential back-off). And that saves you when GC is used, too.
Posted Aug 11, 2023 22:14 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
I had quite a few tools that have these kinds of call sequences, and I don't remember any problems from the third-party tools locking them. Especially when we're talking about files in $TMPDIR.
> If the GC is fast enough to immediately clean up the `fl` descriptor, then everything will work.
CPython without a global interpreter lock
CPython without a global interpreter lock