[lkml]   [2003]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:58    [W:0.025 / U:0.720 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site