configuration files
Chris Pressey
cpressey at catseye.mine.nu
Fri Dec 12 17:05:48 PST 2003
On Fri, 12 Dec 2003 18:37:43 -0500
Dan Melomedman <dan at xxxxxxxxxxx> wrote:
> Chris Pressey wrote:
> > Yes, it's definately cornered the simplicity market.
> >
> > But I keep thinking, how complex could a service monitor possibly be
> > anyway? It's not like it's an XML parser :)
> >
> > T'm no fan of select() either, and I'm sure each of those
> > sub-supervisors doesn't take up much memory, but I also keep
> > thinking that they wouldn't have to exist at all if the
> > super-supervisor could do just a little more work.
>
> You seem to be wanting to minimize for the number of processes, even
> though those processes are very small, and all they're doing is
> waiting for the child to exit so they can restart it.
Kind of. If those processes are "next to not there", then they might as
well actually not be there, right?
> What makes you
> think a more complex single process supervisor that has to do far more
> work is better?
I don't. I also don't think a single process supervisor has to do "far
more work" in this instance.
Honestly, it seems like the main reason there is one supervisor process
per supervised process in runit's model, is to work around the general
lameness of Unix signals. Replace signals with messages, which can
carry more information, and the whole design becomes less contrived.
IMO.
-Chris
More information about the Kernel
mailing list