On Thu, 12 Mar 2015 17:31:36 +0100
Harald Becker <[email protected]> wrote:

> >> Every gathering part grabs the required information, sanitizes,
> >> serializes and then write some kind of command to the fifo. The fifo
> >> management (a minimalist daemon) starts a new parser process when
> >> there is none running and watches it's operation (failure handling).
> >
> > If you are talking about named pipes (created by mkfifo) then your
> > "fifo approach" approach will break here.
> >
> > Once the writing part of the fifo (eg a "gathering part") is done
> > writing and closes the writing part, the fifo is consumed and needs to
> > be re-created. no other "gathering part" will be able to write anything
> > to the fifo.
> 
> ??? You don't understand operation of named pipes!
> 
> Any program (with appropriate rights) may open the "named pipe" (fifo) 
> for writing. As long as data for one event is written in one big chunk, 
> it won't interfere with possible parallel writers. If the fifo device is 
> closed by a writer, this does not mean it vanishes, just reopen for 
> writing and write next event hunk).

What I meant was that reader needs to reopen it too.

> > Basically what you describe as a "fifo manager" sounds more like a bus
> > like dbus.
> 
> It is the old and proven inter process communication mechanism of Unix, 
> nothing new.
> 
> And "fifo manager" sounds really big, it is a really minimalistic 
> daemon, with primitive operation (does never touch the data in the fifo, 
> nor even read that data). It's main purpose beside creating the fifo, is 
> to fire up a conf parser / device operation process when required, and 
> to react on failure of them (spawn a script with args).

and connect the parser to the fifo?

my point is that you need a minimalist daemon that is always there. Why
not let that daemon listen on netlink events instead?

Since it is so simple as you say, why not write a short demo code?

May help me understand what you really mean.

-nc
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to