| Message ID | 20230223204959.408243-1-carlos@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | manual: Add note to process.texi about MT-process fork (Bug 30159) | expand |
* Carlos O'Donell via Libc-alpha: > The forked child of an MT-process may only call AS-safe functions. > --- > manual/process.texi | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/manual/process.texi b/manual/process.texi > index 9307379194..dfdf0923b4 100644 > --- a/manual/process.texi > +++ b/manual/process.texi > @@ -316,6 +316,12 @@ The child doesn't inherit alarms set by the parent process. > The set of pending signals (@pxref{Delivery of Signal}) for the child > process is cleared. (The child process inherits its mask of blocked > signals and signal actions from the parent process.) > + > +@item > +In the case of a multi-threaded parent, the child process may only > +safely call asynchronous-signal-safe functions until the process is > +replaced with a call to an @code{exec} family function. We support calling malloc after fork as an extension. For example, calling opendir after fork to find file descriptors in /proc/self/fd is fairly common. Perhaps add: As an extension relative to POSIX, @theglibc{} supports calling @code{malloc} and other allocation functions after @code{fork}. This only applies to the standard @code{malloc}. Whether this extension is supported by replacement @code{malloc} implementations depends on the replacement. @xref{Replacing malloc}. Thanks, Florian
On 2/23/23 16:32, Florian Weimer wrote: > * Carlos O'Donell via Libc-alpha: > >> The forked child of an MT-process may only call AS-safe functions. >> --- >> manual/process.texi | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/manual/process.texi b/manual/process.texi >> index 9307379194..dfdf0923b4 100644 >> --- a/manual/process.texi >> +++ b/manual/process.texi >> @@ -316,6 +316,12 @@ The child doesn't inherit alarms set by the parent process. >> The set of pending signals (@pxref{Delivery of Signal}) for the child >> process is cleared. (The child process inherits its mask of blocked >> signals and signal actions from the parent process.) >> + >> +@item >> +In the case of a multi-threaded parent, the child process may only >> +safely call asynchronous-signal-safe functions until the process is >> +replaced with a call to an @code{exec} family function. > > We support calling malloc after fork as an extension. For example, > calling opendir after fork to find file descriptors in /proc/self/fd is > fairly common. We support calling a lot of things in reality, but I didn't want to over commit with this change to the manual. I like your narrowly worded addition. > Perhaps add: > > As an extension relative to POSIX, @theglibc{} supports calling > @code{malloc} and other allocation functions after @code{fork}. This > only applies to the standard @code{malloc}. Whether this extension is > supported by replacement @code{malloc} implementations depends on the > replacement. @xref{Replacing malloc}. v2 posted: https://patchwork.sourceware.org/project/glibc/patch/20230223223728.423748-1-carlos@redhat.com/ Checked pdf/html/texi builds and the xref and macros look good.
diff --git a/manual/process.texi b/manual/process.texi index 9307379194..dfdf0923b4 100644 --- a/manual/process.texi +++ b/manual/process.texi @@ -316,6 +316,12 @@ The child doesn't inherit alarms set by the parent process. The set of pending signals (@pxref{Delivery of Signal}) for the child process is cleared. (The child process inherits its mask of blocked signals and signal actions from the parent process.) + +@item +In the case of a multi-threaded parent, the child process may only +safely call asynchronous-signal-safe functions until the process is +replaced with a call to an @code{exec} family function. + @end itemize @deftypefun pid_t _Fork (void)