pipe/fifo, set exception for select() when read end is not open

From: Neal Murphy
Date: Sun May 19 2013 - 19:17:51 EST


I've been looking at the gule hacks I have to use to get inotifywait to work
in shell scripts. So I figgered I would hack inotifywait to look at exceptions
in its select() loop. No joy.

inotifywait loops using select() to look for changes to at least one inotify
FD. Whenever it sees a change, it reads the event and sends it to stdout.
Cool. This works well and uses little CPU time. But there's a problem.

Suppose you have inotifywait monitoring a specific file for a change, such as
"wait for this file to be deleted." And you have piped inotifywait to "while
read a b c". The problem is that when the 'while' loop gets the DELETE event,
it does what is needed and exits. And it is expected that inotifywait will
exit.

But because the file it was watching has been deleted and can cause no more
events, inotifywait will never receive another event, never return from
select(), never write to the pipe, and never know that the pipe's reader
exitted. It will never know that it should exit. Then I got to wondering why
it is that writing to a pipe is the *only* way to know that the reader end is
or has been closed (other than via complicated signalling). And wondering why.

Would it be possible to set an exception on a pipe's or fifo's writer FD when
the reader FD is not open (when there are no readers or when there are none
left)? Would it be reasonable to do this? I imagine a pipe should have a 'last
reader closed' exception, while fifos could benefit from that and/or a 'no
readers' exception.

If this exception existed, inotifywait could watch for read and exception
changes using select(). An exception on stdout would almost certainly mean
that the pipe has been welded shut, so inotifywait should just exit. This
can't be the only example of a program that could benefit from knowing that
one of its output pipes is closed without needing to write to the pipe to find
out.

Thanks,
N

(Please CC me on replies.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/