On 11/9/22 15:15, Alejandro Colomar wrote:
> Hi Henri,

> I've forwarded the emails I got from you to the mailing list, for an
> open discussion.  If I'm missing any, please resend including to the
> list, and preferrably as a reply to this thread.
Oops!

Hi Alex,

Only just now I finished an e-mail, that I intended to send to the list ...

(Sorry, I am that quick anymore)

Regards,
Henri

=====

Subscribe to the list beforehand ...

To: Alejandro Colomar <alx@kernel.org> <==== different e-mail address
To: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: linux-man@vger.kernel.org
Cc: Ken Brown <kbrown@cornell.edu>

Subject Title: [patch] select.2, pipe.7: wfix

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 the O_NONBLOCK openfile status flag has been
 disabled) until data is available; however, if the write end of the pipe is
 closed and the pipe is empty, then read(2) will return with zero."

-----
Attached to this mail, you will find the files server.c and client.c, which
will hopefully clarify what I am talking about.

Finally, I do realize that this message does not contain an official patch,
but I cannot provide one, as I am not set up to provide one. Several years
ago, I "retired from active duty" (Cygwin, not Linux); git(1) and anything
that is useful (required?) in order to be able to properly "submit a patch
to the list" is currently not present on my system.

Attachments: server.c, client.c

====