public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: libc-alpha@sourceware.org,
	 Luca Boccassi <luca.boccassi@gmail.com>,
	Philip Withnall <bugzilla@tecnocode.co.uk>
Subject: Re: [PATCH v4 2/3] posix: Add pidfd_fork
Date: Mon, 22 May 2023 12:12:16 +0200	[thread overview]
Message-ID: <877ct065fj.fsf@oldenburg3.str.redhat.com> (raw)
In-Reply-To: <20230517173516.1988283-3-adhemerval.zanella@linaro.org> (Adhemerval Zanella's message of "Wed, 17 May 2023 14:35:15 -0300")

* Adhemerval Zanella:

> +@deftypefun int pidfd_fork (unsigned int @var{flags})
> +@standards{GNU, sys/pidfd.h}
> +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
> +The @code{fork} function is similar to @code{fork} but return a file
> +descriptor instead of process ID.
> +
> +If the operation is sucessful, there are both parent and child processes
> +and both see @code{pidfd_fork} return, but with different values: it return
> +a value of @code{0} in the child process and returns a file descriptor to
> +child's process int the parent process.  Although the value of @code{0} clashes
> +with @code{STDIN_FILENO}, it also assumed that stardand input is always
> +available so a conformant application will never see a the @code{0} stream
> +being returned to parent as a valid file descriptor.

I think this is a bit ugly.  Maybe pidfd_fork should return the PID/zero
as fork, and store the FD through an int * argument?

The documentaiton should discuss if SIGCHLD is sent for such processes,
and if the PID can be used in waitpid etc.  Ideally we'd have test cases
for this behavior, too. 8-)

I think it would be valuable to support creating subprocesses without
ever sending SIGCHLD on their termination.  Not sure if this should be
the default behavior, or something enabled with a flag.

> diff --git a/posix/fork-internal.c b/posix/fork-internal.c
> new file mode 100644
> index 0000000000..be0d3219af
> --- /dev/null
> +++ b/posix/fork-internal.c

> +void
> +__fork_pos (int state, uint64_t lastrun, bool multiple_threads,
> +	    struct nss_database_data *nss_database_data)

Maybe __fork_post, with a t?

> diff --git a/posix/fork-internal.h b/posix/fork-internal.h
> new file mode 100644
> index 0000000000..3814d851c4
> --- /dev/null
> +++ b/posix/fork-internal.h

> +uint64_t __fork_pre (bool, struct nss_database_data *) attribute_hidden;
> +void __fork_pos (int, uint64_t, bool, struct nss_database_data *)
> +  attribute_hidden;

I suggest to put the arguments into a struct, with struct
nss_database_data as a non-pointer member.  It makes it easier to
document the meaning of the arguments.  And we may have to add more
things in the future.

> diff --git a/sysdeps/unix/sysv/linux/pidfd_fork.c b/sysdeps/unix/sysv/linux/pidfd_fork.c
> new file mode 100644
> index 0000000000..a3ef48ce77
> --- /dev/null
> +++ b/sysdeps/unix/sysv/linux/pidfd_fork.c

> +static int
> +forkfd (void)
> +{
> +  /* The kernel should not change the pidfd for the child, and the returning
> +     value on the parent is always larger than 0 (since a new file descriptor
> +     is always opened with CLONE_PIDFD is the kernel supports it.  */

Missing ).

Thanks,
Florian


  reply	other threads:[~2023-05-22 10:12 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-17 17:35 [PATCH v4 0/3] Add pidfd_spawn, pidfd_spawnp, pidfd_fork, and pidfd_getpid Adhemerval Zanella
2023-05-17 17:35 ` [PATCH v4 1/3] posix: Add pidfd_spawn and pidfd_spawnp (BZ# 30349) Adhemerval Zanella
2023-05-22 10:41   ` Florian Weimer
2023-05-22 10:46     ` Andreas Schwab
2023-05-22 14:18     ` Adhemerval Zanella Netto
2023-05-17 17:35 ` [PATCH v4 2/3] posix: Add pidfd_fork Adhemerval Zanella
2023-05-22 10:12   ` Florian Weimer [this message]
2023-05-22 12:44     ` Christian Brauner
2023-05-22 14:48     ` Adhemerval Zanella Netto
2023-05-17 17:35 ` [PATCH v4 3/3] linux: Add pidfd_getpid Adhemerval Zanella
2023-05-22 13:00   ` Florian Weimer
2023-05-22 17:13     ` Adhemerval Zanella Netto
2023-05-22 13:53   ` Joe Simmons-Talbott

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877ct065fj.fsf@oldenburg3.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=bugzilla@tecnocode.co.uk \
    --cc=libc-alpha@sourceware.org \
    --cc=luca.boccassi@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).