Hi Alex, My modification of pipe.7 (see below) has been revised in order to include both blocking and non-blocking read(2). Attached are the files serverb.c and servernb.c. Mostly comment has been revised in the first one (file was called server.c); in the second file, read(2) is used non-blocking (nb = non-blocking). (previous posts did not include servernb.c) (client.c is also attached once more) Next I will try to provide a proper patch (which will take me some time). --- Proposed modification of pipe.7: see bottom. Regards, Henri On 11/9/22 16:06, J.H. vd Water wrote: [snip] > L.S., > > As result of a problem report against his implementation of select(2) on Cygwin, > it became clear to Ken Brown (and myself) that both the Linux man pages and LPI, > which is a acronym for the book: Linux Programming Interface by Michael Kerrisk, > are not completely correct in describing the behaviour of select(2). > > You can read all about it here: > > - https://cygwin.com/pipermail/cygwin/2022-September/252246.html > > (Re: FIFO issues - response by Ken Brown in which he announces > the correction of his implementation of select() - in Cygwin) > > Basically, select(2) says that the read end of a fifo is "read ready" in case > the write end of the fifo is closed (i.e. select(2) would return in that case, > because read(2) would return in that case). > > However, select(2) blocks on the read end of a pipe in case the write end has > never been opened before (different from read(2)) - and only in that case! [1] > > [1] select(2) on the read end of a pipe will return in case the write end is > closed, once the write has been opened and closed once. > > After studying the Linux man pages (and verification on Fedora 35), I propose > the following modifications: > > 1. > man 2 select ... DESCRIPTION reads: > > "select() allows a program to monitor multiple file descriptors, waiting > until one or more of the file descriptors become "ready" for some class of > I/O operation (e.g., input possible). A file descriptor is considered > ready if it is possible to perform a corresponding I/O operation > (e.g., read(2), or a sufficiently small write(2)) without blocking." > > I suggest to add the following line: > > "However, note that select(2) will block on the read end of a pipe/fifo, if > the write end of the pipe/fifo has never been opened before, unlike read(2) > (read(2) will always return with zero if the write end of the pipe/fifo is > closed - see pipe(7) where the text starts with I/O on pipes and fifos). > > 2. > man 7 pipe ... where the paragraph start with "I/O on pipes and FIFOs": > > "If a process attempts to read from an empty pipe, then read(2) will block > until data is available." > > I suggest to change the above line as follows: "If a process attempts to read from an empty pipe while the write end is open, then read(2) will block (in case of blocking read(2) ), until data is available, and fail with error EAGAIN (in case of nonblocking read(2) ); however, if the write end of the pipe is closed and the pipe is empty, then read(2) will return with zero." ======