On Fri, Mar 13, 2015 at 02:33:44PM -0700, Andy Lutomirski wrote:
On Fri, Mar 13, 2015 at 12:42 PM, Josh Triplett [off-list ref] wrote:
quoted
On Fri, Mar 13, 2015 at 04:05:29PM +0000, David Drysdale wrote:
quoted
On Fri, Mar 13, 2015 at 1:40 AM, Josh Triplett [off-list ref] wrote:
quoted
This patch series introduces a new clone flag, CLONE_FD, which lets the caller
handle child process exit notification via a file descriptor rather than
SIGCHLD. CLONE_FD makes it possible for libraries to safely launch and manage
child processes on behalf of their caller, *without* taking over process-wide
SIGCHLD handling (either via signal handler or signalfd).
Hi Josh,
From the overall description (i.e. I haven't looked at the code yet)
this looks very interesting. However, it seems to cover a lot of the
same ground as the process descriptor feature that was added to FreeBSD
in 9.x/10.x:
https://www.freebsd.org/cgi/man.cgi?query=pdfork&sektion=2
Interesting.
quoted
I think it would ideally be nice for a userspace library developer to be
able to do subprocess management (without SIGCHLD) in a similar way
across both platforms, without lots of complicated autoconf shenanigans.
So could we look at the overlap and seeing if we can come up with
something that covers your requirements and also allows for something
that looks like FreeBSD's process descriptors?
Agreed; however, I think it's reasonable to provide appropriate Linux
system calls, and then let glibc or libbsd or similar provide the
BSD-compatible calls on top of those. I don't think the kernel
interface needs to exactly match FreeBSD's, as long as it's a superset
of the functionality.
We need to be careful with things like read(2), though. It's hard to
write a glibc function that makes read(2) do something other than what
the kernel thinks. Similarly, poll(2) is defined by the kernel. It
would be really nice to be consistent here.
It doesn't sound like FreeBSD implements read(2) on the pdfork file
descriptor at all. If it does, yes, we're not going to be able to be
compatible with that.
- Josh Triplett
On Fri, Mar 13, 2015 at 2:45 PM, [off-list ref] wrote:
On Fri, Mar 13, 2015 at 02:33:44PM -0700, Andy Lutomirski wrote:
quoted
On Fri, Mar 13, 2015 at 12:42 PM, Josh Triplett [off-list ref] wrote:
quoted
On Fri, Mar 13, 2015 at 04:05:29PM +0000, David Drysdale wrote:
quoted
On Fri, Mar 13, 2015 at 1:40 AM, Josh Triplett [off-list ref] wrote:
quoted
This patch series introduces a new clone flag, CLONE_FD, which lets the caller
handle child process exit notification via a file descriptor rather than
SIGCHLD. CLONE_FD makes it possible for libraries to safely launch and manage
child processes on behalf of their caller, *without* taking over process-wide
SIGCHLD handling (either via signal handler or signalfd).
Hi Josh,
From the overall description (i.e. I haven't looked at the code yet)
this looks very interesting. However, it seems to cover a lot of the
same ground as the process descriptor feature that was added to FreeBSD
in 9.x/10.x:
https://www.freebsd.org/cgi/man.cgi?query=pdfork&sektion=2
Interesting.
quoted
I think it would ideally be nice for a userspace library developer to be
able to do subprocess management (without SIGCHLD) in a similar way
across both platforms, without lots of complicated autoconf shenanigans.
So could we look at the overlap and seeing if we can come up with
something that covers your requirements and also allows for something
that looks like FreeBSD's process descriptors?
Agreed; however, I think it's reasonable to provide appropriate Linux
system calls, and then let glibc or libbsd or similar provide the
BSD-compatible calls on top of those. I don't think the kernel
interface needs to exactly match FreeBSD's, as long as it's a superset
of the functionality.
We need to be careful with things like read(2), though. It's hard to
write a glibc function that makes read(2) do something other than what
the kernel thinks. Similarly, poll(2) is defined by the kernel. It
would be really nice to be consistent here.
It doesn't sound like FreeBSD implements read(2) on the pdfork file
descriptor at all. If it does, yes, we're not going to be able to be
compatible with that.
There's an argument that using read(2) for stuff like this is a bad
idea. If anyone tried to do this in C++ (or any other OO language):
class GenericInterface
{
public:
virtual void DoAction(const char *value, size_t len) = 0;
};
class Process : public GenericInterface
{
public:
virtual void DoAction(const char *value, size_t len) = 0;
};
void Kill(Process *p)
{
p->DoAction("kill", 4);
};
They'd be re-educated very quickly. This is like duck typing, but
taken to a whole new level: *everything* is a duck, and ducks have a
grand total of three operations.
On the other hand, this seems to be UNIX tradition. It's not as if
using echo on pidfds is going to be a common idiom, though.
In any event, we should find out what FreeBSD does in response to
read(2) on the fd.
--Andy