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?
posix file-io named-pipes nonblocking fifo
Jim Dennis Apr 25 '11 at 19:26 2011-04-25 19:26
source share