Re: SIGCHLD and sigaction()

[Mouse]

>> Perhaps it would need a new flavour of file descriptor, [...]
> Linux has apparently done this: pidfd (file descriptors representing
> a process).  The idea is that you can pass them to various system
> call variants that otherwise take pids, without the risk that the
> process has exited in the mean time and the pid re-used.

I've been thinking about something like that myself, starting with
AF_PID sockets, then deciding they wouldn't/couldn't work (as think I
mentioned in this thread, the socket infrastructure really wants the
contents of a socket to be independent of who's accessing it).
Personally, I've wanted it as a way to provide an out-of-band channel
to userland programs (like a control command channel for various
daemons), but...hmm.

Feels strange to find an idea I like coming from Linux.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: SIGCHLD and sigaction()

[Rhialto]

On Sat 15 Aug 2020 at 16:46:13 -0400, Mouse wrote:
> Personally, I don't like it; I think signals should be much like
> hardware interrupts in that a second instance happening before the
> first is serviced gets silently merged.  If you want some sort of
> queued notification of child death, it seems to me a much righter, much
> more UNIXy, tack to take is to add something like AF_CHILD sockets or
> some such and get child death notifications that way.  (Actually, I'm
> not sure sockets would work without severe hackery; too much of the
> socket machinery assumes the data in a socket is independent of who
> reads from it.  Perhaps it would need a new flavour of file descriptor,
> akin to kevent or timerfd descriptors.

Linux has apparently done this: pidfd (file descriptors representing a
process). The idea is that you can pass them to various system call
variants that otherwise take pids, without the risk that the process has
exited in the mean time and the pid re-used. See
https://man7.org/linux/man-pages/man2/pidfd_open.2.html

Personally I'd think you should be able to get pidfds from the /proc
file system, but here Linux seems to have missed a chance.

-Olaf.
-- 
Olaf 'Rhialto' Seibert -- rhialto at falu dot nl
___  Anyone who is capable of getting themselves made President should on
\X/  no account be allowed to do the job.   --Douglas Adams, "THGTTG"


signature.asc
Description: PGP signature