Why is a read-only named block open?

I noticed a couple of weird things about working with named pipes (FIFOs) under various UNIX variants (Linux, FreeBSD, and MacOS X) using Python. The first and perhaps most annoying is that attempts to open an empty / unoccupied FIFO for reading will be blocked (unless I use os.O_NONBLOCK with a lower level os.open() ). However, if I open it for reading / writing, I will not block.

Examples:

 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 

I'm just curious. Why is the block open calls and not any subsequent read operation?

I also noticed that a non-blocking file descriptor can exhibit different behaviors in Python. In the case where I use os.open() with os.O_NONBLOCK for the initial open operation, then os.read() seems to return an empty string if the data is not ready in the file descriptor. However, if I use fcntl.fcnt(f.fileno(), fcntl.F_SETFL, fcntl.GETFL | os.O_NONBLOCK) then os.read throws an exception ( errno.EWOULDBLOCK )

Is there another flag set by normal open() that is not set in the os.open() example? How do they differ and why?

+52
posix file-io named-pipes nonblocking fifo
Apr 25 '11 at 19:26
source share
1 answer

This is exactly how it is defined. On the Open Group page for the open() function

 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. 
+63
Apr 25 '11 at 20:16
source share
— -



All Articles