Guido, I've said multiple times (and in this very bug report!) that the program isn't sensible.  That isn't the point.  Having multiple threads even just reading from the same stream without explicit user locks isn't sensible either, and you can't have it both ways:  on Python-Dev you said the point to using FLOCKFILE in get_line was to prevent core dumps in case the user was doing multiple reads by *accident*.

That's fine:  I agree, and a file open for update is likely just as prone to mixed read/write "accidents".

As far as the std goes, input following output should have intervening fflush, fseek, fsetpos or rewind; while output following input should-- unless input hit EOF --have intervening fseek, fsetpos or rewind (not fflush, though!  fflush immediately after input is undefined).

Adding flags to the file object doesn't seem to help much, because the combo of e.g. "I'm doing a read now" and "I'm setting the 'reading' flag" needs to be atomic in a threaded world else it's unreliable (and then you're back to Python-level locks to repair that).

Does this blow up on Linux for you?  That's more interesting to me.  I've implemented stdio in the past, and I think what's happening here is quite likely what it looks like:  a bug in MS's file-locking (the _cnt member just doesn't go negative if the FILE* struct is properly locked during manipulations!).  If that's true, this is surely rare enough that we can wait for MS to fix it.  But in the meantime, it is a way to get Python to coredump on Windows.