在使用Python在各种UNIX(Linux,FreeBSD和MacOS X)下处理命名管道(FIFO)时,我注意到了一些奇怪的事情。第一个,也许是最令人讨厌的是,尝试打开空闲/空闲FIFO只读将被阻止(除非我使用os.O_NONBLOCK
与较低级别os.open()
调用)。但是,如果我打开它进行读/写,那么我就不会阻塞。
示例:
f = open('./myfifo', 'r') # Blocks unless data is already in the pipe
f = os.open('./myfifo', os.O_RDONLY) # ditto
# Contrast to:
f = open('./myfifo', 'w+') # does NOT block
f = os.open('./myfifo', os.O_RDWR) # ditto
f = os.open('./myfifo', os.O_RDONLY|os.O_NONBLOCK) # ditto
我只是好奇为什么。为什么open open阻塞而不是后续的一些读操作?
此外,我注意到非阻塞文件描述符可以表现为Python中的不同行为。如果我使用os.open()
和os.O_NONBLOCK
进行初始打开操作,那么如果文件描述符上没有准备好数据,则os.read()
似乎返回一个空字符串。但是,如果我使用fcntl.fcnt(f.fileno(), fcntl.F_SETFL, fcntl.GETFL | os.O_NONBLOCK)
,则os.read
会引发异常(errno.EWOULDBLOCK
)
我的open()
示例没有设置普通os.open()
设置的其他标志吗?它们有何不同?为什么?
答案 0 :(得分:69)
这就是它的定义方式。从open()
功能的打开组页面
O_NONBLOCK
When opening a FIFO with O_RDONLY or O_WRONLY set: If O_NONBLOCK is
set:
An open() for reading only will return without delay. An open()
for writing only will return an error if no process currently
has the file open for reading.
If O_NONBLOCK is clear:
An open() for reading only will block the calling thread until a
thread opens the file for writing. An open() for writing only
will block the calling thread until a thread opens the file for
reading.