Date: Fri, 1 Dec 2023 21:58:04 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Alan Somers <asomers@freebsd.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: fork-like functions and async-signal-safety Message-ID: <ZWo6zO5yUbTuKnFQ@kib.kiev.ua> In-Reply-To: <CAOtMX2hi-7PfpPVNUsMxtNaQXx8-7ucAf3hvuH1732u1xPNaBg@mail.gmail.com> References: <CAOtMX2hi-7PfpPVNUsMxtNaQXx8-7ucAf3hvuH1732u1xPNaBg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 01, 2023 at 09:26:51AM -0700, Alan Somers wrote: > fork() is not async-signal-safe, and therefore can't be used in a > signal handler. ... if the process is multithreaded. > Nor can it be used from a multithreaded program > (unless the child only executes aysnc-signal-safe functions). More precisely, it is not guaranteed to work in the child of the fork of mt process. I believe (with high confidence) that it works for the FreeBSD implementation. > > _Fork(), OTOH, is async-signal-safe. According to fork(2), "It can be > used safely from signal handlers, but then no userspace services > (malloc(3) or rtld(1)) are available in the child if forked from > multi-threaded parent." > > But can you use malloc and rtld in the child if _Fork was invoked from > a multi-threaded process, but not from a signal handler? That's not > clear to me. No. > > And what about pdfork? Neither sigaction(2) nor pdfork(2) specify > whether pdfork is async-signal-safe. Is it? pdfork() is same as fork(). > > FYI the reason I'm asking is that I'm trying to determine whether it > would be possible to make cap_init() async-signal-safe.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZWo6zO5yUbTuKnFQ>