Re: SIGCHLD and sigaction()

2020-08-19 Thread Kamil Rytarowski
On 19.08.2020 20:02, Roy Marples wrote:
> On 18/08/2020 20:52, Mouse wrote:
 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.
> 
> You can relax.
> FreeBSD did it first for Capsicum.
> 
> https://www.freebsd.org/cgi/man.cgi?query=pdfork=2
> 
> Roy

Hi,

I have got a draft work on this.

It's composed of:

1. New id_t type in P_PIDFD.
2. sigsendset(2) + sigsend(3), picked from SVID (Solaris, etc) It's a
generalized version of kill(2). It allows specifying P_PIDFD.
3. waitid supporting new id type: P_PIDFD.

Linux is close to the above, except reinventing the wheel instead of
picking sigsendset(2) + integration with /proc.

FreeBSD went with a distinct direction and invented new semantics of
process file descriptors, that differs to references over pid_t. For
example whenever you close(2) a file descriptor, it kills the process.
You also must wait for process events in FreeBSD using kevent(2). This
introduced incompatibilities with the established UNIX semantics. Linux
went a different path and whenever a process dies, we get ESRCH, which
is sensible as it avoids e.g. killing a random process with recycled pid_t.

We want process file descriptors to reference process handles through
PID namespaces, for hopefully upcoming support of containers.



signature.asc
Description: OpenPGP digital signature


Re: SIGCHLD and sigaction()

2020-08-19 Thread Roy Marples

On 18/08/2020 20:52, Mouse wrote:

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.


You can relax.
FreeBSD did it first for Capsicum.

https://www.freebsd.org/cgi/man.cgi?query=pdfork=2

Roy