Re: [Jython-dev] fileno support is not in jython. Reason?

Philip, many thanks for your hard work on java.nio PyFile's; it will
modernise jython I/O in a neat and elegant fashion, and enable jython
to capitalise on all the really excellent features in java.nio, with
performance being highest on the list (or my list at least :-)
[Alan]
>> I think we have a strong case to get the cpython folks to change the
>> cpython mmap API.
[Philip]
> We can't really make the non-portable argument any longer now that
> we're supporting faux file descriptors, though. IronPython also
> supports fake file descriptors (as integers FYI).
Hmm, do you mean "now that we CAN support faux FDs"? Note that we can
support faux FDs on files *only*, not on any other type of I/O stream,
e.g. sockets, pipes, etc, so we would be introducing an asymmetry into
jython by supporting them. If we do support them, I think we will then
find that users will expect to be able to pass these faux file
descriptors to e.g. select.select, etc, and expect them to be operated
upon, e.g. multiplexed. This cannot happen on jython;
java.nio.FileChannels do NOT implement SelectableChannel; FileChannels
can never be multiplexed.
I seem to remember Mehendran saying that he chose to make the first
parameter of mmap a file OBJECT, not a file descriptor. I think this
is the right way to go; mmap taking a file descriptor is an historical
accident, IMHO, because mmap was first implemented in a language
(cpython) that supported file descriptors. The API would have made
just as much sense (more sense, IMHO) if an actual file object were
passed instead.
Are you saying "now that we DO support faux FDs"? Is that because your
new java.nio PyFile implementation supports faux FDs?
As to whether the faux FDs (if we do decide to support them) should be
integers or not, then I think the extra work to make them integers is
pointless; they should be opaque handles on a system resource; an
extra level of indirection doesn't make the implementers or the users
lives any easier. You can't add integer FDs together, or multiply
them, i.e. do integer operations on them. They might just as well be
java.nio.channels.SelectableChannel or java.io.FileDescriptor objects.
Lastly, as you know, the primary I/O type for java is
java.nio.channels.Channel; all I/O objects implement this core
interface, and *all* java.nio-derived I/O operations take objects
implementing this interface as parameters. If we are going to
implement a "universal" I/O handle in jython, then it should be based
on Channels, not file descriptors, faux or otherwise.
So I think that ALL jython I/O objects should implement a getchannel()
method, which returns the underlying Channel for the I/O object.
getchannel() would be the direct equivalent of fileno() in the cpython
world. (We could call the method fileno() as well, as I discussed in
my message to python-dev on the subject, but I think that would be
misleading, and would lead to misunderstandings by the users). But
this is a language philosophy issue that I do not claim to have
authority on. I think this is an issue that requires a decision by the
BDFL.
[Alan]
>> Lastly, the absolute best possible solution would be to reimplement
>> PyFile to use only java.nio. Jython is currently split between the
>> java.io and java.nio worlds (primarily because of the new asynch
>> support on sockets), and it is causing problems
[Philip]
> I'm just about finished with this.
Fantastic! That's great news. I checked out the pyfile-nio branch last
night, haven't had a chance to review yet. But if it's passing all the
tests, then that's very encouraging. Lastly, I don't have enough
knowledge of the existing PyFile implementation to be able to judge
whether the new implementation is ready for the prime time, i.e. to
become *the* core File implementation. But I certainly want for it to
become the core PyFile implementation ASAP; it will re-introduce
orthogonality into jython I/O.
[Alan]
>> 1. See bug [ 1744567 ] Simultaneous read & write on socket FileWrapper
>> causes hang
>> http://sourceforge.net/tracker/index.php?
>> func=detail&aid=1744567&group_id=12867&atid=112867
[Philip]
> I have a fix for that in the ticket. It actually doesn't require
> PyFile nio, so it can be applied to the 2.2 branch too.
Nice; I like the idea of re-using the cpython _fileobject; it is
well-exercised code that is already proven in the field.
+1 for solving the socket.makefile() problem this way.
> The code for the PyFile nio is now on branches/pyfile-nio, though,
> for anyone wanting to take a look.
Have downloaded a copy; will take a close look soon.
All the best, and thanks again.
Alan.

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details