On Mon 01-07-13 22:08:28, Chinmay V S wrote: > > 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. Ah right. If you wrote the data to the file using write(2), you'd see IN_MODIFY 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? There are more places that can sync a file (e.g. sync_file_range() or it is disputable whether sync(2) should generate the event or not). Generally it seems to me that you just need to broadcast an event notification to a group of processes and the fact that you use inotify is a bit arbitrary. > 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. Well, you could create eventfd descriptor for each reader in the writer, pass it to each reader via Unix domain sockets and use that for notification. Passing of actual data can still be done via mmap. But I agree that it's likely more code than just using inotify. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- 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
