为什么命名管道的只读打开会阻塞？
为什么命名管道的只读打开会阻塞？
提问于 2011-04-26 03:26:49
在使用MacOS处理各种风格的UNIX (Linux、FreeBSD和Python )下的命名管道(FIFO)时，我注意到了一些奇怪的地方。第一个，也可能是最令人恼火的是，试图打开一个空/空闲的只读FIFO将会阻塞(除非我在较低级别的os.open()调用中使用os.O_NONBLOCK )。但是，如果我以读/写的方式打开它，那么我就不会收到阻塞。
示例：
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调用阻塞，而不是一些后续的读操作？
此外，我还注意到，非阻塞文件描述符可以在Python中表现出不同的行为。在我使用os.open()和os.O_NONBLOCK进行初始打开操作的情况下，如果文件描述符上的数据尚未就绪，则os.read()似乎返回一个空字符串。但是，如果我使用fcntl.fcnt(f.fileno(), fcntl.F_SETFL, fcntl.GETFL | os.O_NONBLOCK)，则os.read会引发一个异常(errno.EWOULDBLOCK)
在我的os.open()示例中，普通的open()是否设置了其他标志？它们有什么不同?为什么？
回答 1
Stack Overflow用户
回答已采纳
发布于 2011-04-26 04:16:01
这就是它的定义方式。在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.页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/5782279
复制相关文章
相似问题
腾讯云开发者
