On Sun, Feb 12, 2017 at 8:36 AM, Arne Goedeke <[email protected]> wrote:
> I had a look at your branch. My feeling is that this would be better
> placed into a seperate module. Maybe there will be more things that
> might be useful when interacting with systemd?
Maybe; if so, Stdio.Port would need to expose a way for a module to
say "here, make one of you from this fd".
> If I understand the API correctly, then the number of passed file
> descriptors will be placed into an environment variable. Why does this
> not work purely in pike?
>
> int n = (int)getenv("LISTEN_FDS");
> array a = allocate(n);
>
> for (int i = 0; i < n; i++) a[i] = Stdio.File(3+i);
You can't accept() on a Stdio.File. That technique would probably work
for an active (connected) socket, but not for a passive (listening)
one.
The reason I wrote the code as a patch to Pike rather than doing it in
my own application is that Pike doesn't expose a way to construct a
Stdio.Port from any existing fd other than stdin. Maybe there should
be an API for that instead? I don't know of any other situations that
would use it, though, and it's good to check LISTEN_PID before
claiming the FDs. It might also be useful to parse LISTEN_FDNAMES and
use that in the sprintf("%O") of the Port, which would help with
debugging; not a huge feature, but one that can easily be added in the
future if it's done this way, whereas there's no easy way to control
that from pure Pike code.
ChrisA
