[Python-Dev] Patch 595601

[Tim Peters]

[Skip Montanaro]
> Isn't this a case of "so don't do that"?

I think so, but it's apparently debatable (since people at Zope Corp are
debating it <wink>), and it doesn't excuse Python from segfaulting even if
so.

> I've never encountered this before, but then I don't close files in one
> thread while another holds a reference.

There's no problem with closing a shared file; the problem can arise only if
one thread is trying to "do something" with a file at the same time another
thread is trying to close that file.

> Would it be reasonable to raise an error or warning if a file's
> close() method was called when the reference count was greater than 1?

I don't think so.  Shane Hathaway sketched an approach adding (in effect) an
"in use" count to the FILE* contained by a Python file object.  That count
would be incremented and decremented, under protection of the GIL, around
pieces of implementation code that passed on the FILE*.  *Then* it would
make sense to raise an exception if a close() call occurred while that count
was above its initial value.  This count is independent of how many
references there may be to the Python file object.