Hello Simon, Tuesday, November 14, 2006, 4:02:09 PM, you wrote:
>>>>>> #ifdef mingw32_HOST_OS >>>>>> if ((how & O_WRONLY) || (how & O_RDWR) || (how & >>>>>> O_APPEND)) return _sopen(file,how,_SH_DENYRW,mode); >>>>>> else >>>>>> return _sopen(file,how,_SH_DENYWR,mode); >>>>>> #else >>>>>> return open(file,how,mode); >>>>>> #endif >> i.e. no sopen at all? in this case, other parts of library should >> make proper locking for unix. > Yes, we do. See > http://darcs.haskell.org/packages/base/cbits/lockFile.c. after some thought, i still want to complain. locking files while it's open on Windows and using special procedure on Unix is internal trick of Handle-based I/O library. it's bad that this trick was exposed as non-consistent behavior of c_open call which, by its name, is proposed for general use by other libs i think that proper design was either to make such function internal to GHC.Handle module, or incorporate all necessary locking logic into the c_open/c_close and make exhaustive doc-comment to warn users thinking that c_open should be the same as raw C open() call in current situation when some code besides of GHC.* may rely on this strange inconsistent behavior i think at least commenting it will be a good idea -- Best regards, Bulat mailto:[EMAIL PROTECTED] _______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
