[IronPython] fepy socket seek

Dino Viehland dinov at exchange.microsoft.com
Fri Nov 17 19:20:57 CET 2006

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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] 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

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.


users mailing list
users at lists.ironpython.com

More information about the Ironpython-users mailing list