On Mon, Oct 28, 2013 at 11:30 AM, Lennart Poettering
lenn...@poettering.net wrote:
So yeah, cool feature, and I'd be very happy to see this in PID 1, but I
am very sure we shouldn't merge this tool like this!
Can I get some pointers on how to do it in PID 1? If I start them the
same way as the
On Mon, 21.10.13 04:59, David Strauss (da...@davidstrauss.net) wrote:
This daemon is a proof-of-concept that manages a process pool of
(usually) socket-activated child processes. It exploits the ability to
have multiple processes accept() on the same socket, allowing the
kernel to
From: David Strauss da...@davidstrauss.net
---
.gitignore | 1 +
Makefile.am| 13 ++
src/socket-process-pool/Makefile | 1 +
src/socket-process-pool/socket-process-poold.c | 247 +
This daemon is a proof-of-concept that manages a process pool of
(usually) socket-activated child processes. It exploits the ability to
have multiple processes accept() on the same socket, allowing the
kernel to distribute requests among the children. We've talked about
adding this to systemd
On Monday, October 21, 2013, David Strauss da...@davidstrauss.net wrote:
This daemon is a proof-of-concept that manages a process pool of
(usually) socket-activated child processes. It exploits the ability to
have multiple processes accept() on the same socket, allowing the
kernel to
On Mon, Oct 21, 2013 at 7:08 AM, Tom Gundersen t...@jklm.no wrote:
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?
On Mon, Oct 21, 2013 at 4:59 AM, David Strauss da...@davidstrauss.net wrote:
I've already noticed that it doesn't work so well with multiple processes and
EPOLLIN to do
accept() callbacks (like in systemd-socket-proxyd), but I'm looking for
options there.
Thanks to some helpful advice [1]
