Linux vs Windows I/O Buffer问题

wpdzyx

前两天在另外一个帖子中跟别人争论readline/writelines的问题时，特意运行了程序测试，结果在windows下跟在linux下的执行结果竟然不一样。

1. #!/usr/bin/python
   
2. 
   
3. fpath = 'abc.txt'
   
4. fin = open(fpath,'r+')
   
5. result = fin.readline()
   
6. print result
   
7. result=fin.writelines(['111\n'])
   
8. fin.close
   

复制代码

abc.txt内容如下:
abc
abc
abc
abc
abc

结果在linux下运行结果：
abc
111
abc
abc
abc

但是在windows cygwin下执行的结果为：
abc
abc
abc
abc
abc
111

这是为什么呢？ 是因为linux与windows I/O Buffer实现不一样导致吗？

linux_c_py_php

你的linux glibc版本问题, 默认FILE应该是全缓冲的, 你的看起来是个无缓冲的.

  1 abc
  2 abc
  3 abc
  4 abc
  5 abc
  6 111

毫无问题, windows和linux是一致的.

wpdzyx

回复 2# linux_c_py_php


    那就奇怪了。我在公司和家里的电脑上的linux环境下都试了。有什么方式可以获取系统当前的I/O buffer的设置吗？ 我记得C语言中只有setbuf可用。不知python中是否有getbuf类似的应用。

Linux版本：
Linux version 2.6.35-22-generic (buildd@rothera) (gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu4) ) #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC 2010

Glib版本：
GNU C Library (Ubuntu EGLIBC 2.12.1-0ubuntu6) stable release version 2.12.1, by Roland McGrath et al.
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.5 20100909 (prerelease).
Compiled on a Linux 2.6.35 system on 2010-09-10.
Available extensions:
        crypt add-on version 2.1 by Michael Glad and others
        GNU Libidn by Simon Josefsson
        Native POSIX Threads Library by Ulrich Drepper et al
        BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC

linux_c_py_php

[liangdong@bb-browser-test00.vm.baidu.com py_project]$ uname -a
Linux bb-browser-test00.vm.baidu.com 2.6.9xenu_7-0-0-0 #5 SMP Thu Sep 16 22:15:55 CST 2010 x86_64 x86_64 x86_64 GNU/Linux
[liangdong@bb-browser-test00.vm.baidu.com py_project]$ gcc -v
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.5/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.5 20051201 (Red Hat 3.4.5-2)

看样你的版本比较高, 这个问题似乎得到了修正.

bleem1998

python的一致性真不匝地啊

106033177

回复 1# wpdzyx
这个程序是错误的。读和写不能紧挨着 这个c标准是明确指出了，你非要违反标准，那么程序的行为取决于具体的c实现，如果你用微软的 runtime的话 结果是文件内容没有任何改变。
When a file is opened with update mode ('+' as the second or third character in the
above  list of mode argument values), both input and output may be performed on the
associated stream. However, output shall not be directly followed by input without an
intervening call to the fflush function or to a file positioning function (fseek,
fsetpos,or rewind), and input shall not be directly followed by output without an
intervening call to a file positioning function, unless the input operation encounters end-
of-file.

   

wpdzyx

回复 6# 106033177


    的确！这个程序是有错误的。当时也是争论这个。现在拿出来就是想明确一下Linux下与windows下的缓冲方式是否有不一样。现在看来，有可能是因为使用的Library不一样导致。如果seek指定了位置，在linux/windos下表现是一致的.

106033177

回复 7# wpdzyx
缓冲方式open()的时候是可以指定的  http://docs.python.org/library/functions.html#open
open(name[, mode[, buffering]])        
The optional buffering argument specifies the file’s desired buffer size: 0 means unbuffered, 1 means line buffered, any other positive value means use a buffer of (approximately) that size. A negative buffering means to use the system default
即使你指定了缓冲方式，这个程序的行为依然不是你预期的。比如xp下微软的runtime用open(fpath,'r+',1)得到的结果是
abc
a111
bc
abc
abc

   

linux_c_py_php

编程中有个原则:

对于错误的做法, 知道为什么错, 然后永远不使用它.

我觉得此前的帖子已经理解了为什么错, 这里就不必再纠结了, 只是看C Standard Library怎么实现而已, 与我们无关, 幸亏我一直用的是gcc 3.x, 并且从来都是fseek清buffer, 因为我知道底层是怎么实现的就足够了.

bleem1998

"output shall not be directly followed by input without an intervening call to the fflush function or to a file positioning function"

加fseek果然是王道