On 16/05/2016 18:21, Orchid Win7 v1 wrote:
> On 16/05/2016 01:47 PM, scott wrote:
>> 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.
>
> So you're mostly worried about latency. (?)

Yes, but we're talking a tenth of a second being fine here, microseconds 
are not needed!

>> 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?
>
> Writing to a file (or, more likely, a *named pipe*) seems like a
> reasonable way to do this, especially considering the low frequency of
> updates. Hell, at this speed, you could almost create / delete an entire
> empty file as your flag signal!
>
> You could instead try TCP (or UDP), but I'd expect that to have much
> higher overhead. I don't know if Unix sockets are any quicker.
>
> Alternatively, learn how dbus works? Or MPI. Or one of the other
> existing messaging frameworks.
>
> Personally, if it were me, I'd go with named pipe. But I guess that's
> just because I've used it before and I know how it works...

Thanks for the ideas everyone.

Just looked up named pipes - it seems you can only have a single 
"reader"? I need more than one process to be able to see the signal.

Sockets should work ok, or as you state, just create/delete an empty 
file somewhere. I'll have to experiment. I guess at some point I might 
want to expand the signal to more than one pin, so being able to 
communicate an "int" rather than a "bool" would actually be more scalable.

Post a reply to this message