On 16/05/2016 06:26 PM, Le_Forgeron wrote:
> A low latency signaling system... with low volume of data.
>
> one of the fastest might be using kill (2),

Damn, I hadn't even thought of that. Good call.

> 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.

You could do something like have the listener send SIGUSR1 to the root 
process, which then remembers the PID of the process that signalled it, 
and signals it back until it dies.

(I'm not sure of the security implications of different processes 
signalling each other; I *believe* you just need to know the PID of the 
destination, but I may be wrong...)

> 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)

Yeah, I'm told writing signal handles is fraught with "subtle" race 
conditions and such.

> 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.

Another excellent solution I hadn't thought of. Though I'm unclear on 
how you do this in Linux; do you just mmap the same backing file from 
two different processes? Regardless, that should avoid the need to 
switch to kernel mode to send messages - although it does seem to 
require the receiver to poll for them...

> 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.

Indeed.

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

In my day job, I wrote some stuff that's powered by AT-SPI, which uses 
dbus under the hood. I don't know much about it, though. (I gather it 
uses Unix sockets to do its actual work... And a central daemon to 
gather and route messages...)

Post a reply to this message