when read buffer size is 2048, it work , but buffer size is 48 or other number, write call will be blocked, why?

 if(FD_ISSET(w_fd, &w_set)){ write(w_fd, w_buf, sizeof(w_buf)); printf("write count:%d\n", write_count++); } 

If select tells you an fd is writable, that means you can write at least one byte. The threshold may be higher than 1, depending on how the FIFO buffer is managed, but it certainly doesn't mean you can write 4096 bytes without blocking.

This code is statically wrong and must set both fds to non-blocking mode (and be ready to handle EAGAIN/EWOULDBLOCK return codes appropriately) to be reasonably robust.

The reason some read buffer sizes expose the problem is to do with whether you can reach a situation where the FIFO is empty enough that w_fd shows as writeable, but too full for the write to complete (so it blocks).

You could trivially confirm or falsify this by attaching a debugger to the blocked process, or running it under strace. These are both perfectly normal tools you should learn to use.

The problem appears to be in checking both r_set and w_set after a single select -- possibly a race condition where the read or write invalidates the result.

This is a robust version, with extra debug, and some results.

It is important to do any available reads before writes. If you give the writes precedence, it will fill the fifo (probably up to 64KB) before the reads get a look-in. This may be part of the race condition in your original code.

// xSelect.c #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/select.h> #include <fcntl.h> #include <unistd.h> int main(int argc, char* argv[]){ if(argc < 2){ puts("err argv"); return -1; } ssize_t r_res, w_res; int r_fd, w_fd; r_fd = open(argv[1], O_RDWR); w_fd = open(argv[1], O_RDWR); fprintf (stderr, "r_fd %d, w_fd %d\n", r_fd, w_fd); fd_set r_set; fd_set w_set; char w_buf[4096]; char r_buf[1235]; for (int j = 0, w = 0; j < 20; j++) { FD_ZERO(&r_set); FD_ZERO(&w_set); FD_SET(r_fd, &r_set); FD_SET(w_fd, &w_set); int ret = select(w_fd + 1, &r_set, &w_set, NULL, NULL); if(FD_ISSET(r_fd, &r_set)){ r_res = read(r_fd, r_buf, sizeof(r_buf)); fprintf (stderr, "Read %zd\n", r_res); } else if(w++ < 3 && FD_ISSET(w_fd, &w_set)){ w_res = write(w_fd, w_buf, sizeof(w_buf)); fprintf (stderr, "Write %zd\n", w_res); } else { fprintf (stderr, "Tick\n"); } } return 0; } 

$ make xSelect && echo Run && ./xSelect xSelect.fifo cc xSelect.c -o xSelect Run r_fd 3, w_fd 4 Write 4096 Read 1235 Read 1235 Read 1235 Read 391 Write 4096 Read 1235 Read 1235 Read 1235 Read 391 Write 4096 Read 1235 Read 1235 Read 1235 Read 391 Tick Tick Tick Tick Tick $ 

EDIT: I may have over-thought this. I do not think the r_set and w_set are directly affected by a single read and/or write: they are however obsoleted by those actions.

In your original code, w_fd will always be writeable until the FIFO is completely full. So if you do equal numbers of long writes and short reads, the writer will eventually hang. If your short reads are 2048 bytes, then you will need about 32 cycles to fill the fifo: if short reads are 48, you will fill the fifo with 17 cycles.

Obviously, the average rates of writing and reading must be equal in the long-term. Typically, the kernel achieves this by not scheduling the writer (which is in a different process), but your code enforces one read, one-write. So the w_set.w_fd eventually becomes unset.

One problem is that the select() does not know how much data you plan to write. If the fifo has space for one byte, w_fd is writeable. I do not know whether the write is truncated, or blocked, or failed, and whether having both fds using the same fifo makes any difference. It is not even worth testing, because the answer may depend on the OS, and whether we are using a fifo or a socket, or some other factor. Your code should be written to deal with a partial write, an error returning EAGAIN, and blocking.

Your code suffers from completely filling the fifo, and mine from completely emptying the fifo unnecessarily after each write. A proper demo should tune (or randomise) its behaviour to explore the possibilities.