[IronPython] fepy socket seek
christopher at baus.net
Thu Nov 16 09:36:15 CET 2006
> Solution: Check if stream is seekable in PythonBinaryReader too. If
> it's not seekable, it doesn't make much sense to set Position "to
> synchronise" anyway.
I've been tracing this bug tonight, and I feel concerned about it. The
CRLF reader allows seeking even when the underlying stream doesn't. That
doesn't make much sense.
If a socket file is created with CRLF endlines, and a write operation is
performed, some data will be missed on subsequent reads because the read
position has been advanced by the number of bytes that have been written.
Here are the issues I see.
1) As Seo mentioned, before attempting to advance the read position
following write, check if the reader is not NULL and seekable. If not do
2) PythonTextCRLFReader should not allow seeking when the underlying
stream is not seekable.
3) This might apply to other readers which manage their own position.
4) This code doesn't appear to be reentrant. If multiple threads write
and/or read to a file, position will be in an unstable state.
End result: Files based on non-seekable streams don't work. File
operations are not thread safe.
I have some concerns about the implemetation of this module. This might
be a deal killer for me.
More information about the Ironpython-users