The problem of using sockets rather than named pipes is that each UNIX socket requires more POSIX shared memory increasing the system resource base requirements. Named pipes just use normal process memory which keeps system requirements less. How Lennart failed to mention that in the systemd presentation is insane.
Sent from my Windows Phone ________________________________ From: post-sysv<mailto:[email protected]> Sent: 1/6/2015 12:03 PM To: Laurent Bercot<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: Re: s6 init-stage1 On 01/06/2015 07:48 AM, Laurent Bercot wrote: > Interesting. Thanks for the heads-up - I had heard of tsort, but didn't > know exactly what it does. > > However, I'd like a tool that knows what steps it can parallelize. > A sequential output is great for functions name in a piece of code, > but for services, the point is to start as many as possible in > parallel, and minimize the amount of synchronization points. > > For instance, given > 1 2 > 3 4 > meaning 2 should happen after 1, and 4 should happen after 3, > tsort gives > 1 > 3 > 2 > 4 > but instead, I need something like > 1 3 > 2 4 > because 1 and 3 can happen in parallel, and same for 2 and 4. > > AFAICT, tsort cannot do that. (make might not be able to either, > but since it's more complex, it's harder to tell.) > About that. Actually, I'm not even certain if there exists a service manager that *actually* starts processes in parallel. Usually what I've noticed is that most of the time what is really meant is that services are started asynchronously, or at best concurrently. Debian and other formerly sysvinit-based distributions had what was known as a "Makefile-style concurrent boot". To the best of my knowledge, this was done using a combination of LSB initscript headers through insserv, and a program called startpar. Reading the source code of startpar, I was surprised to see that it does its job through a primitive form of socket activation in the run() function where it allocates a so-called "preload" socket and determines exit status by its availability for connection. Secondary routines including meddling with ptys and file descriptors to curb interleaving and make sure the execution state is clean and free of potentially blocking operations. Makes me wonder if Poettering ever read it, though his ostensible inspiration was from launchd. That said, it does show that the systemd supporters have overhyped the novelty of "socket activation" (inetd) even more significantly than I had previously thought. Someone should make note of this. In any event, I'm under the impression that most so-called parallel service starters are really ones that start asynchronously in a clean execution state, as true parallelism and even concurrency sounds conceptually quite difficult, particularly when you keep in mind that many boot processes are I/O-bound, primarily. systemd itself has a complex dependency system at its backbone, with socket activation not being a mandatory thing from what I've learned. It also blocks on occasion to fulfill start jobs, so evidently it has synchronization methods that are contrary to its claims. If someone can clarify this issue or point to any concurrent/parallel schemes for starting services at boot time that have been implemented, that would be appreciated.
