Le 16/05/2016 14:47, scott a écrit :
> On my pi I'm running raspbian, and have a process running as root to read a pin on
the GPIO (connected to a PIR). Only root can read the GPIO pins, but obviously I don't
want large, complex programs running as root just because they need to read a pin on
the GPIO.
> 
> What's the best way for this root process to "broadcast" to other (non-root)
processes when that pin goes high? It will only happen at maximum frequency of about
every 2 seconds, but any delay between the pin going high and the other processes
seeing it should be minimal.
> 
> I did think about using a file, that was write permission only for root, but
readable by everyone, that seems like a lot of overhead though (and what if root tries
to write to it as someone else is reading it?). In Windows I might consider using a
broadcast message with
> the PostMessage API function, is there something similar for Linux?

A low latency signaling system... with low volume of data.

one of the fastest might be using kill (2), but the root process need to get a
list of registered process to signal, and each registered process must have
registered a handling routine for the signal.
Number of available signal is low, so not a scalable solution for too much items.
There is a few restriction on the handling routine too. And signals do not stack
(signaling twice the same signal before it got handled is not to be seen)

To perform the registration... might depend on the number of processes which must
be signaled. (and do not forget to have mechanism to cancel the registration
when one process exits, even with a crash)

If processes can or need to perform active monitoring, a shared memory segment
can be used. You just need to be able to select a common key.
For a fixed-number of processes architecture, the registration process might be
a shared memory segment, but you would need a kind of keep-alive sub-part in it.

A substitute to a real file would be a named pipe (with a bit of locking, it can even
provides information about the other end being dead), served by the root process.

The interest of "file" like solution is using select() to dispatch event.

If you are in a graphical desktop, there might be some messaging/bus system too, but
latency is another story.

Post a reply to this message