Messages in this thread | | | Date | Tue, 25 Nov 2003 16:10:29 -0800 | From | jw schultz <> | Subject | Re: POSSIBLE BUG: certain writes to pipe block (after select()) |
| |
On Tue, Nov 25, 2003 at 01:20:18PM +0100, Ondrej Jombik wrote: > [ Please CC me in the answer as I am not in the list. ] > > I discovered that certain writes to filedescriptor created with pipe() > system call will block even if select() previously returned change on > that filedescriptor -- of course select() returned change in "write" > fd_set. > > While doing a deep investigation, I find out, that this write only > blocks if more than 4096 bytes are written. This is certain for 2.4.20, > 2.4.21 and 2.6.0-test7 kernels. Other kernels were untested. What is > more interesting is the fact, that PIPE_BUF kernel constant (defined in > the file /usr/include/linux/limits.h) has value equal to 4096 bytes. > > So when writting 4097 bytes write() blocks. When writting 4096 bytes it > does not. However I had never seen during my information hunt an > information, that only maximum PIPE_BUF bytes can be written into > filedescriptor created with pipe() system call. I think this is the > point of the whole thing, but I'm confused why this is not written > anywhere. > > But anyway, I would like to mention, that expected behaviour is, that > write() will write 4096 bytes (so return value from write() syscall is > 4096) and the rest should be up to user. So it has to be userspace deal > to wait for writing remaining byte(s).
This is correct behavior. popen opens the file descriptors with having default flags. Therefore they have blocking enabled. See fcntl(2). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |