On Sun, 15 Mar 2015 02:30:33 +0100 Harald Becker <[email protected]> wrote:
> Hi Isaac ! > > On 14.03.2015 08:10, Isaac Dunham wrote: > > Basic concept is that it creates a fifo, and treats the success of mkfifo > > as a lock to determine whether it's the daemon or a writer. > > If it's the daemon, it will > > fork; > > in the child: > > exec the parser with the fifo as stdin > > in the parent: > > set a SIGCHLD handler that respawns the parser if the fifo is not empty, > > open the fifo to write, > > dump the environment into the fifo > > sleep > > Congratulations, you implemented the base functionality, I intended, > except I use some command line parameter to distinguished between > hotplug helper and parser. This is mainly for increased stability and > flexibility with no extra cost (due to BB startup / option handling less > code than fifo check). > > ... beside not (yet) implemented failure management > > ... has your approach a problem: The write side of the pipe (fifo) is > closed as soon as you exit the hotplug helper, which let the parser die > immediately too (except other hotplug run at exactly the same moment). > This way you get extra parser starts when events have slight delays. > With the possibility of race conditions (which need complicated failure > check and handling). > > Therefore it's better to let a small process hold the fifo open and > available (skips need to recreate on every event). For no extra cost > this process can do the parser startup, signal management and failure > checks, as this automatically shares code otherwise also required in the > netlink part. > > ... and you got my "fifo manager". But this means that you have replaced the tiny always-in-memory netlink socket activator with a bigger always-in-memory "fifo manager". I don't see how that improves anything. -nc _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
