Sensor Value PropertiesChanged Events

[Andrew Jeffery]

On Tue, 2 Feb 2021, at 11:56, Ed Tanous wrote:
> 
> The third one is a little more out there.  We could change the
> sensor.Value.Value property into an FD type, and point to a memmapped
> area of memory into which we write the current sensor value.  That
> way, the "sensor value" on dbus rarely changes, but you can always
> read the current state of the sensor with zero overhead or context
> switching to the sensor processes.  If this works, it has the
> potential to speed up most sensor polling operations by an order of
> magnitude, but seems hard to do, and has a lot of questions.  Does
> inotify work on mmaped files?  How do FD permissions work when sent
> over dbus?  How do you "lock" the memory region to write it (or do you
> not have to)?
> 

So... a little repo that I pushed recently might help out with this approach:

https://github.com/amboar/shmapper

It's a shared-memory implementation of the mapper daemon, but setting that 
aside for the moment, the implementation contains a shared library, libshmap, 
discussed in the README:

https://github.com/amboar/shmapper#libshmap

libshmap allows you to treat process-shared-memory like regular heap memory*, 
and also wraps up the pthread locking and condition signalling primitives in a 
way that they can be placed into the shared memory region without concern.

So in brief, you could implement your out-there idea on top of libshmap, and it 
has solutions for most of the questions you list there already:

* Permissions would be enforced by ownership of the sensor shared library 
(libraries?) built on top of libshmap.
* Locking the memory regions can be done with shmap_mutex or shmap_rwlock, and
* Notification can be done using shmap_mutex and shmap_condition

I've been thinking about how I could do condition notification over a 
file-descriptor so you could poll it for updates to the shared memory. I 
haven't got anything concrete yet, but that would provide async monitoring too.

Cheers,

Andrew