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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
