Explain how to read a single inotify event.
PATCH 1/1 Explain how to read a single inotify event.
man7/inotify.7:
- Explain how to read a single inotify event.
- Add missing "struct" in explanation of event size.
Kind regards,
Signature · 1 line
James Hunt
Quoted 1 line
From
2c2e9150661fc12142725f97e3cebf8ff64e1264Mon Sep 17 00:00:00 2001
From: James Hunt <james.hunt-GeWIH/[email protected]>
Date: Tue, 6 Dec 2011 09:33:51 +0000
Subject: Explain how to read a single inotify event.
Also added missing "struct" to sizeof().
--- man7/inotify.7 | 24 +++++++++++++++++++++++- 1 files changed, 23 insertions(+), 1 deletions(-)
man7/inotify.7 +23 -1
@@ -144,7 +144,7 @@ including the null bytes; the length of each .I inotify_event structure is thus -.IR "sizeof(inotify_event)+len" . +.IR "sizeof(struct inotify_event)+len" . The behavior when the buffer given to .BR read (2)
@@ -417,6 +417,28 @@ be aware that by the time you create a watch for the new subdirectory, new files may already have been created in the subdirectory. Therefore, you may want to scan the contents of the subdirectory immediately after adding the watch. + +To read a +.B single +event requires the buffer provided to +.BR read (2) +be large enough to hold the event. However, since inotify employs +variable-length events for files in a watched directory (via the +.I name +field), it is not possible to know exactly how big such a +buffer should be since the event itself has not yet been read. One +method to overcome this limitation is to start with a buffer of size +.I sizeof(struct inotify_event) +and attempt to read the event. If this fails with +.BR EINVAL "," +continue to increase the buffer size by one byte up to +.I "sizeof(struct inotify_event)+NAME_MAX" +until +.BR read (2) +does not return +.BR EINVAL "." +Note that this technique is not particularly efficient. + .SH "BUGS" In kernels before 2.6.16, the .B IN_ONESHOT
Signature · 1 line
1.7.5.4
A message that is not in the archive (sent off-list or not yet received): 4EDDE325.2080203-GeWIH/[email protected]
Michael Kerrisk (man-pages)
AppliedHi James,
Quoted 4 lines · James Hunt
man7/inotify.7:
- Explain how to read a single inotify event.
- Add missing "struct" in explanation of event size.
Re your patch:
man7/inotify.7 including the null bytes; · line 147
Quoted 8 lines
man7/inotify.7 +1
-1@@ -144,7 +144,7 @@ including the null bytes; the length of each .I inotify_event structure is thus -.IR "sizeof(inotify_event)+len" . +.IR "sizeof(struct inotify_event)+len" .
Applied.
Quoted 21 lines
man7/inotify.7 +15
-0The behavior when the buffer given to .BR read (2)@@ -417,6 +417,28 @@ be aware that by the time you create a watch for the new subdirectory, new files may already have been created in the subdirectory. Therefore, you may want to scan the contents of the subdirectory immediately after adding the watch. + +To read a +.B single +event requires the buffer provided to +.BR read (2) +be large enough to hold the event. However, since inotify employs +variable-length events for files in a watched directory (via the +.I name +field), it is not possible to know exactly how big such a +buffer should be since the event itself has not yet been read. One +method to overcome this limitation is to start with a buffer of size +.I sizeof(struct inotify_event) +and attempt to read the event. If this fails with +.BR EINVAL "," +continue to increase the buffer size by one byte up to
man7/inotify.7 be aware that by the time you create a watch for the new subdirectory, · line 444
Quoted 10 lines
man7/inotify.7 +7
-0+.I "sizeof(struct inotify_event)+NAME_MAX" +until +.BR read (2) +does not returnvi +.BR EINVAL "." +Note that this technique is not particularly efficient. + .SH "BUGS" In kernels before 2.6.16, the .B IN_ONESHOT
I've just now added a note to the page that specifying a buffer size of at least "sizeof(struct inotify_event) + NAME_MAX + 1" is sufficient to read *at least* one event. My question is, why do you want to propose this technique for reading a *single* event.?
Cheers,
Michael
Signature · 7 lines
Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface"; http://man7.org/tlpi/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): CAKgNAkgB3_SUsnH0-c8X6Lute8amtEkw0VtrsCqFGWn+c4yfQA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 2 lines · Michael Kerrisk (man-pages)
My question is, why do you want to propose this technique for reading a *single* event.?
It could be useful in multithreaded/multiprocess apps that rely on an inotify descriptor to distribute work to a thread pool. accept() and mq_receive() users do it all the time.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20120424181112.GA1458-yBiyF41qdooeIZ0/[email protected]
Hello Eric,
Quoted 7 lines · Eric Wong
Quoted 2 lines · Michael Kerrisk (man-pages)
My question is, why do you want to propose this technique for reading a *single* event.?
It could be useful in multithreaded/multiprocess apps that rely on an inotify descriptor to distribute work to a thread pool. accept() and
mq_receive()users do it all the time.
In that case, I'd have thought it more efficient to have a manger thread read blocks of events and hand them out to members of the pool. This would be more efficient than performing multiple read() calls. The difference for accept() and mq_receive() is that they retrieve single "events" *by definition*.
Cheers,
Michael
Signature · 7 lines
Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface"; http://man7.org/tlpi/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html