Thanks both of you for looking into this so deeply. Sorry we haven't been more responsive to this - I originally tuned out this thread thinking it wasn't related to the core.
I've opened CodePlex bug #5756 for the seekable check (http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemId=5756). This is definitely just broken. I've marked this as a 1.1 bug. I've opened CodePlex bug #5757 for the thread-safety issue (http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemId=5757). I agree this is broken in principle, but I wonder why this would be a shop-stopper. Do you have a scenario where you can reliably have multiple writers to a single stream w/o any external synchronization necessary? For example what if the resulting I/O could be interleaved but the file still correctly tracked it's position information? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Baus Sent: Thursday, November 16, 2006 12:36 AM To: Discussion of IronPython Subject: Re: [IronPython] fepy socket seek > 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 _______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
