> 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 nothing. 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. http://baus.net/ _______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
