> But why can't you use current IN_MODIFY event? > Initially i registered a "catch all" inotify watch on the mmap-ed file by calling inotify_add_watch() with IN_ALL_EVENTS in the "reader" process. But modifications to the file by mmap-ing it in the "writer" process did NOT trigger the inotify watch. Even calling msync() did NOT trigger any inotify events. (BTW, Is this expected behaviour?? v2.6.37 on ARMCortexA8, rootfs on NAND) The file was mapped using MAP_SHARED to ensure that no copies were made in memory and the changes made by the "writer" process are being flushed to the file. Hence added support for IN_SYNC event in the inotify framework. https://gist.github.com/TheCodeArtist/5874669 IMHO, this is a well justified addition to the inotify mechanism. Since it simplifies the creation of an event notification framework for IPC, is any reason why IN_SYNC should *NOT* be mainlined? PS: Once again, i would really really welcome any suggestions to implement a simple high performance notification mechanism for IPC using any existing alternatives. Running a "patched" kernel is something i would like to avoid. System requirements: a. Single data "writer" process. b. Multiple "reader" processes, each to be notified of every update by the writer. c. Processes "writer" and "readers" NOT related. No per-determined order of execution. d. Events may NOT be dropped. regards ChinmayVS -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
