Message12069

Tackling your points in reverse, when something is removed in a later version I think it's a hint it wasn't the right idea. But as Guido points out (https://bugs.python.org/issue595601#msg59340), the whole i/o system is different in 3.

When you look at what PyFile_IncUseCount does (just a tripwire), it's not the lock I expected from the documentation. But in the source code and original issue it becomes clear that the concern was that operations after close, called by a *badly-written* program, may result in a C-level crash and this trick turns it into a Python IOError.

In CPython, macros count up/down immediately before/after you release the GIL. So uses (of FILE_BEGIN_ALLOW_THREADS and FILE_END_ALLOW_THREADS) define regions where actions on a file may happen concurrently with taking the GIL and closing the file (an error). The count is equal to the number of threads using the file but not holding the GIL. We get an IOError if close() is called while this count is non-zero, which will occur outside any of these regions, by the one thread that at that point holds the GIL. But we don't hava a GIL, so bracketing all uses of the underlying file with atomic up and down operations doesn't provide the benefit you seek in Jython.

We check the file is still open before every i/o operation but we don't synchronise the methods to make this effective in the face of concurrency. We should, if an unhandled Java exception in *badly-written* programs a concern. (I think the original author decided not, but synchronisation is not as expensive as it used to be.) And then the macros we're talking about, when they appear in CPython/JyNI extensions, should mean take and release the inherent lock on the FileIO.

FileIO.__int__() is troublesome but not really the topic here. JyNI and some low-level Python will need to reach the C-level fd or FILE*, I accept. Java has taken away the reflective access to it unless you run with an --add-exports, and this will be unacceptable to some users, but probably only where C extensions are too. (Or they'll be sophisticated enough to manage the risks of both.) My point is only that we can't casually make Jython as a whole depend on --add-exports, as we do now (#2656).