Le 17/05/2016 à 09:18, scott a écrit :
>
> 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.

named pipe are unidrectional, and a single reader is the thing.

The server (root process) should create a root_pipe to which it will 
read "long" data.

The other process should create their own my_name_pipe to which they 
would read short data.

How it could work:

One other process opens in write mode the root_pipe (it get a file 
descriptor), use a write-lock on that file descriptor, send the name 
(aka path) of its my_name_pipe (as encapsulated data, beware of variable 
length), relequish the write-lock on the file descriptor and might even 
close the file descriptor.

The root process, upon having something to read in the root_pipe, 
retrieve the name of the named pipe of the other process (this is where 
variable length can be painful), then opens the other's name pipe in 
write mode and stack the file descriptor in its internal structure.

Upon event to signal, the root process loops for each stacked file 
descriptor and sent a byte.



Added sugar, detection of dead processes by root process:
The other process should lock the file descriptor it use to read its 
named pipe, as soon as possible and forever. (lockf or flock, you need 
to dive into their man pages, one of them is the right one to use)

The root process, before writing a byte for the event, should try to 
lock the same named_pipe (via its file descriptor) and that try should 
fail. If it succeed, the reading end is dead, and there is no need to 
send a byte, just close the file descriptor and remove it from the 
internal structure.

Caveat: that solution does not work over an NFS partition.


Extra strawberry on top: the root process should put the outgoing named 
pipe in non-blocking mode, to avoid being frozen by a full pipe and a 
stalled reader.

Post a reply to this message