[Python-Dev] Re: RELEASED Python 2.3.1 (original) (raw)
Tim Peters tim.one at comcast.net
Sun Sep 28 18:11:41 EDT 2003
- Previous message: [Python-Dev] Re: RELEASED Python 2.3.1
- Next message: [Python-Dev] Re: RELEASED Python 2.3.1
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Guido]
Tim, trust me. The scenario you go on to sketch is unique to Windows.
I would rather trust the test program, but I don't see much point to the argument (if that's what this is): if os.fsync has gone missing on platforms that "used to" support it, of course that's a serious regression.
fsync() was invented on Unix. On that platform, there's never a need to do fsync() to allow another process to see the right data. fsync()'s effect is just not visible at the abstraction level presented by the kernel. fsync() is needed because sometimes (e.g. through a power or kernel failure) the kernel's abstraction is broken. Everybody except you who is arguing for fsync()'s importance does so because they have experienced (or fear to experience) crashes.
It's a bug in the Windows implementation of Unix-style I/O that a commit() call (which is what fsync() is aliased to in posixmodule.c on Windows) is needed in order to ensure that other processes see what a process wrote.
The test driver (and ZODB) use buffered I/O, not unbuffered POSIX I/O. Assuring that writes done to buffered streams are visible to other processes is trickier than Martin's reliance on the write(2) man page, since write(2) isn't involved in the chain.
Given that fsync() on Windows doesn't have the configuration problem that started all this,
I don't know whether Cygwin Python suffers the same problem. If it does, then people running ZODB under Cygwin 2.3.1 (which I don't believe has been released yet) are in for nasty surprises if they run repozo.py under the "native" Windows Python. I've tried this under Cygwin 2.2.2 (see other email). Since that did have os.fsync(), but the native Windows Python didn't at that time, my best guess is that Cygwin Python is affected.
I'm not sure how your argument for fsync() can help convince Martin that we should do a 2.3.2 release ASAP.
It's enough for me that a function that used to be there has gone away without good reason. It's easier to cut a new release than argue about how much trouble the missing os.fsync should cause, as people have already poured more energy into complaining about it than would be needed to cut a new release.
- Previous message: [Python-Dev] Re: RELEASED Python 2.3.1
- Next message: [Python-Dev] Re: RELEASED Python 2.3.1
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]