On 08/06/2015 21:21, Avery Payne wrote:
> I'm not specifically speaking about a socket required by a daemon.
> I'm talking about using sockets for activation via UCSPI, similar to
> the old inetd concept.
Ah, using superservers, of the ucspi-tcp/ipsvd/s6-networking flavour.
Got it. And I agree with your assessment: as with supervision suites,
there are similarities but no definite standard API, and in order to
support them you'd have to do some unification work again.
Honestly, superservers are pretty much orthogonal to the service
dependency issue. I like superservers for several reasons
(non-exhaustive list: they factor the total amount of code running
on the machine, they factor long-running executables for significant
memory savings, they factor root (or otherwise trusted) code, they
make configuration easy via pluggable command-line utilities - which
appeals to extreme chain loading freaks like me) but they really
don't play a part in the whole service startup order shenanigans.
No matter whether a service is implemented via a monolithic daemon or
a superserver, it will grab its socket at start and then attempt to
serve clients, with the exact same dependencies and operation order
in both cases.
So, your choice to use or not to use them makes no difference here.
Or am I missing something?
> The question was along the lines of "sure it's something we can do,
> but does that mean we should do it to begin with?"
Our only hope against the quicker, easier, more seductive competition
is to do things right. ;)
--
Laurent
Received on Mon Jun 08 2015 - 19:49:00 UTC