HEllo Emil, On 3/19/19 11:35 PM, Emil Fihlman wrote: > Version 5.00 (http://man7.org/linux/man-pages/man7/inotify.7.html) > >> If no events have so far occurred, >> then, assuming a blocking file descriptor, read(2) will block until >> at least one event occurs (unless interrupted by a signal, in which >> case the call fails with the error EINTR; see signal(7)). > > but https://bugzilla.kernel.org/show_bug.cgi?id=195711 says that since > 3.8 the call is restarted, which is also my experience (and huge > annoyance). However, I am not on the latest Kernel but 4.9.0-8-amd64 > so I dont know if it has been changed back. A cursory search over the > kernel code says that last change with inotify and EINTR in same > context was removing EINTR and replacing with ERESTARTSYS > (https://github.com/torvalds/linux/commit/1ca39ab9d21ac93f94b9e3eb364ea9a5cf2aba06). > > There really should be caveat that the syscall is probably restarted > when reading from an inotify file-descriptor. This has important > implications on how one can use the interface (ie simple blocking > style is absolutely not enough and some multiplexing is always > required for reliable execution even in simple programs). The text that you quote above from inotify(7) says "see signal(7))". That page says: If a blocked call to one of the following interfaces is inter‐ rupted by a signal handler, then the call is automatically restarted after the signal handler returns if the SA_RESTART flag was used; otherwise the call fails with the error EINTR: ... * read(2) from an inotify(7) file descriptor (since Linux 3.8; beforehand, always failed with EINTR). This seems to me to cover all; the details, or do you mean something is still missing? Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
