Notify / Alarm when a file changes with a memory card displayed

Question

I am currently sharing data (<1KB) between several processes by memory matching. 1 "author" process and several "readers" process all mmap the same file.

Currently, reader processes need to constantly monitor updates. Reader processes continue to poll the mmap-ed region to see if any new data has been written.

Typical use (and existing implementation) :
The Writer process is a journal that saves occasional additions of new data (each on a new line). At any given time, there can be one or more “reader” processes that are interested in any new data that is generated by the “writer” process. Also, instead of having an infinitely expanding file, it is a circular buffer, that is, after a fixed number of lines, the answering machine turns back and starts overwriting the file from the very beginning with new data. The header field in this file tracks the position of the latest data, that is, the current head.

In short, systems try to mimic the semantics of msgsnd () and msgrcv () with two additional caveats:

• Multiple Reader Support
  When a “writer” sends one million, several notifications must be sent, one for each active “reader”.
  -> Currently, it is achieved, since each "reader" constantly polls the "head" field and reads new data when it changes.

• Persistence (file supported)
  If any read / write process abruptly stops, system recovery should be as simple as restarting the process.
  -> Currently, when shared IPC data is supported in the mmap-ed file supported on disk.

What would be - Fast (low latency) and
- Lightweight (low processor usage) alternative for implementing some kind of event mechanism for notifying reader processes every time the mmap-ed area is changed by the recording process?

NOTE During the reading process, adding inotify to look at the mmap -ed file did NOT lead to any events when the mmap-ed memory was updated by the write process (even after calling msync () ).

Answer 1

_{(publication of a practically used solution for future use)}

Using this patch, which adds mmap-ed file support for inotify ,

• reader can use inotify infrastructure
• to monitor changes in mmap-ed file at significant / important intervals.
• which are initiated by the writer process calling sync() in the same mmap-ed file.

Answer 2

In all blocking messages, the reader captures data, and no other reader can read it.

• You can create a chain of readers. This is bad, because in your case the processes may suddenly end.
• Use multiple channels. Each time a reader is created, he may ask the author to open the handset, and then the reader will be able to subscribe to this channel and read it. In addition, the writer can send the reader a copy of the current state of the data, unless readers can access it on their own.
• Use signals. You can send a signal from the author to all readers after each entry.

The tough question though ... That's all I got ...