<br><br>On Monday, October 21, 2013, David Strauss <<a href="mailto:david@davidstrauss.net">david@davidstrauss.net</a>> wrote:<br>> This daemon is a proof-of-concept that manages a process pool of<br>> (usually) socket-activated child processes. It exploits the ability to<br>
> have multiple processes accept() on the same socket, allowing the<br>> kernel to distribute requests among the children. We've talked about<br>> adding this to systemd core, but that will probably take a great deal<br>
> more work than running it as PID > 1.<br><br>Hi David,<br><br>This is a cool feature. However, it seems to me that adding it to the core makes much more sense, that way the children can be managed properly by systemd as real services. What problems do you see with adding this to pid1?<br>
<br>Cheers,<br><br>Tom<br><br>> This code is definitely not ready to commit for multiple reasons (man<br>> pages, argument parsing being confused by children getting --args, and<br>> more), but I'd like feedback on the general idea. I've already noticed<br>
> that it doesn't work so well with multiple processes and EPOLLIN to do<br>> accept() callbacks (like in systemd-socket-proxyd), but I'm looking<br>> for options there [1].<br>><br>> I would like this to work well with (1) systemd-socket-proxyd, (2)<br>
> Twisted socket activation, and (3) node.js socket activation. If it<br>> can handle all of those well, I'll be confident in the design.<br>> Currently, the options for running pools of Twisted or node.js<br>
> processes are clunky, like fronting a set of instance services with<br>> haproxy.<br>><br>> [1] <a href="http://stackoverflow.com/q/19493498/450218">http://stackoverflow.com/q/19493498/450218</a><br>> _______________________________________________<br>
> systemd-devel mailing list<br>> <a href="mailto:systemd-devel@lists.freedesktop.org">systemd-devel@lists.freedesktop.org</a><br>> <a href="http://lists.freedesktop.org/mailman/listinfo/systemd-devel">http://lists.freedesktop.org/mailman/listinfo/systemd-devel</a><br>
>