Re: Sensor Value PropertiesChanged Events

["Andrew Jeffery" <andrew@aj.id.au>]

On Wed, 3 Feb 2021, at 10:41, Andrew Jeffery wrote:
> 
> 
> 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.

Alternatively, set permissions on the sem or shm files (currently libshmap just 
sets them to 0660), or given that you're probably going to wrap access up in an 
API anyway, split the producer and consumer APIs and have the consumer API only 
expose const values.

Anyway, interested in your thoughts.

Andrew