Message12064

Author stefan.richthofer
Recipients jeff.allen, stefan.richthofer, zyasoft
Date 2018-08-03.22:56:24
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1533336986.38.0.56676864532.issue2699@psf.upfronthosting.co.za>
In-reply-to
Content
Via FileIO.__int__() Jython offers access to the file handle which a user could use in C code (e.g. by JNI or JNR or so independently from JyNI) to access the file directly. However according to PyFile_IncUseCount doc (https://docs.python.org/2/c-api/file.html#c.PyFile_IncUseCount) one would have to call PyFile_IncUseCount/PyFile_DecUseCount API around such an access. Since this API is missing in Jython a user currently does not have a chance to do it right. "Who would directly use the file handle to access the file?" one might ask, which I guess is why it was never implemented. Now there is an answer: C-extensions!

The actual reason I come up with is that we are currently implementing PyFile API in JyNI, see https://github.com/Stewori/JyNI/issues/11#issuecomment-410309767. FileIO.__int__ giving public access to the handle also in Jython made me realize that this API also has a use case in Jython itself, an exotic one though. Not so exotic for C extensions via JyNI.

How to implement it in FileIO is straight forward. A use counter would be maintained (AtomicInt I suppose) and close() would fail if called while the counter is >0. Main question is whether the API should be actually in PyFile rather than or in addition to FileIO. In that case it would simply forward the counter calls to FileIO if the underlying IO object (private TextIOBase file;) is actually backed by a FileIO.

If we can agree this should be added I would like to get it into 2.7.2, so setting the milestone accordingly. Otherwise it would block the next JyNI release potentially for a long time.

Without this implementation JyNI would have to monkeypatch FileIO (e.g. wrap it into a JyNIFileIO). While possible this would be a hassle.
Please tell me if there is already some way to prevent FileIO from closing (in a concurrent access setting) or if I overlook some simpler solution. I looked into FileChannelAPI but it seems that a close is never prevented. Instead, the other accessing threads would be interrupted with a AsynchronousCloseException, see https://docs.oracle.com/javase/7/docs/api/java/nio/channels/InterruptibleChannel.html.
History
Date User Action Args
2018-08-03 22:56:26stefan.richthofersetrecipients: + stefan.richthofer, zyasoft, jeff.allen
2018-08-03 22:56:26stefan.richthofersetmessageid: <1533336986.38.0.56676864532.issue2699@psf.upfronthosting.co.za>
2018-08-03 22:56:25stefan.richthoferlinkissue2699 messages
2018-08-03 22:56:24stefan.richthofercreate