public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org>
Subject: Re: [PATCH v4 4/4] posix: Add _Fork [BZ #4737]
Date: Thu, 24 Jun 2021 10:47:20 +0200	[thread overview]
Message-ID: <87y2azlkdj.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <20210623184354.395316-5-adhemerval.zanella@linaro.org> (Adhemerval Zanella via Libc-alpha's message of "Wed, 23 Jun 2021 15:43:54 -0300")

* Adhemerval Zanella via Libc-alpha:

> +@deftypefun pid_t _Fork (void)
> +@standards{GNU, unistd.h}
> +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
> +The @code{_Fork} function is similar to @code{fork} but does not issue
> +any atfork callback registered with @code{pthread_atfork} neither reset
> +any internal state or locks (such as the malloc one) and only setup a
> +minimal state required to call async-signal-safe functions (such as raise
> +or execve).

Maybe:

+The @code{_Fork} function is similar to @code{fork}, but it does not invoke
+any callbacks registered with @code{pthread_atfork}, nor does it reset
+any internal state or locks (such as the @code{malloc} locks).  In the
+new subprocess, only async-signal-safe functions may be called, such as
+@code{dup2} or @code{execve}.
+
+The @code{_Fork} function is an async-signal-safe replacement of @code{fork}.
+It is a GNU extension.

> diff --git a/posix/tst-_Fork.c b/posix/tst-_Fork.c
> new file mode 100644
> index 0000000000..f14da12d5a
> --- /dev/null
> +++ b/posix/tst-_Fork.c

> +/* _Fork is async-signal-safe, so check if it can successfully issue
> +    a new process in a signal handler.  */
> +static int
> +singlethread_signal_test (void)
> +{
> +  xsignal (SIGUSR1, &sigusr1_handler);
> +  /* Assume synchronous signal handling.  */
> +  xraise (SIGUSR1);
> +  TEST_COMPARE (sigusr1_handler_ran, 1);

This test tests using a synchronous signal, so it doesn't add much
value in my opinion.

> +/* Different than fork, _Fork does not execute any pthread_atfork
> +   handlers.  */
> +static int
> +singlethread_atfork_test (void)
> +{
> +  pthread_atfork (atfork_prepare, atfork_parent, atfork_child);
> +  singlethread_test ();
> +  TEST_COMPARE (atfork_prepare_var, false);
> +  TEST_COMPARE (atfork_parent_var, false);
> +  TEST_COMPARE (atfork_child_var, false);

Use TEST_VERIFY (!atfork_child_var) etc.?

> diff --git a/posix/unistd.h b/posix/unistd.h
> index d9d8929f71..fa06c890ba 100644
> --- a/posix/unistd.h
> +++ b/posix/unistd.h
> @@ -781,6 +781,13 @@ extern __pid_t fork (void) __THROWNL;
>  extern __pid_t vfork (void) __THROW;
>  #endif /* Use misc or XPG < 7. */
>  
> +#ifdef __USE_GNU
> +/* This is similar to fork, however it does not run the atfork handlers
> +   neither reinitialize any internal locks in multithread case.
> +   Different than fork, _Fork is async-signal-safe.  */
> +extern __pid_t _Fork (void) __THROWNL;
> +#endif

Should this be _THROW (no callbacks)?  Do we have to specify the
returns_twice attribute?

Thanks,
Florian


  reply	other threads:[~2021-06-24  8:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-23 18:43 [PATCH v4 0/4] Add _Fork implementation Adhemerval Zanella
2021-06-23 18:43 ` [PATCH v4 1/4] posix: Consolidate fork implementation Adhemerval Zanella
2021-06-24  8:15   ` Florian Weimer
2021-06-24 11:32     ` Adhemerval Zanella
2021-06-23 18:43 ` [PATCH v4 2/4] posix: Do not clobber errno by atfork handlers Adhemerval Zanella
2021-06-24  8:19   ` Florian Weimer
2021-06-24 11:05     ` Adhemerval Zanella
2021-06-24 11:19       ` Florian Weimer
2021-06-24 11:32         ` Adhemerval Zanella
2021-06-23 18:43 ` [PATCH v4 3/4] Consolidate pthread_atfork Adhemerval Zanella
2021-06-24  8:22   ` Florian Weimer
2021-06-24 11:32     ` Adhemerval Zanella
2021-06-23 18:43 ` [PATCH v4 4/4] posix: Add _Fork [BZ #4737] Adhemerval Zanella
2021-06-24  8:47   ` Florian Weimer [this message]
2021-06-24 13:34     ` Adhemerval Zanella
2021-06-28  8:52       ` Florian Weimer
2021-06-28 18:10         ` Adhemerval Zanella

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=87y2azlkdj.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    /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).