Date: Fri, 10 Sep 2021 00:19:30 +0100 From: Jessica Clarke <jrtc27@freebsd.org> To: Konstantin Belousov <kib@FreeBSD.org> Cc: "src-committers@freebsd.org" <src-committers@FreeBSD.org>, "dev-commits-src-all@freebsd.org" <dev-commits-src-all@FreeBSD.org>, "dev-commits-src-main@freebsd.org" <dev-commits-src-main@FreeBSD.org> Subject: Re: git: 49ad342cc10c - main - Add _Fork() Message-ID: <42166E5E-A749-4FC7-A834-8A35D58706EF@freebsd.org> In-Reply-To: <202108031819.173IJgPB060470@gitrepo.freebsd.org> References: <202108031819.173IJgPB060470@gitrepo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3 Aug 2021, at 19:19, Konstantin Belousov <kib@FreeBSD.org> wrote: >=20 > The branch main has been updated by kib: >=20 > URL: = https://cgit.FreeBSD.org/src/commit/?id=3D49ad342cc10cba14b3a40ba26cf8bb21= 50e2925a >=20 > commit 49ad342cc10cba14b3a40ba26cf8bb2150e2925a > Author: Konstantin Belousov <kib@FreeBSD.org> > AuthorDate: 2021-08-02 09:50:32 +0000 > Commit: Konstantin Belousov <kib@FreeBSD.org> > CommitDate: 2021-08-03 18:19:32 +0000 >=20 > Add _Fork() >=20 > Current POSIX standard requires fork() to be async-signal safe. = Neither > our implementation, nor implementations in other operating systems = are, > and practically it is impossible to make fork() async-signal safe = without > too much efforts. Also, that would put undue requirement that all = atfork > handlers should be async-signal safe as well, which contradicts its = main > use. >=20 > As result, Austin Group dropped the requirement, and added a new = function > _Fork() that should be async-signal safe, but it does not call = atfork > handlers. Basically, _Fork() can be implemented as a raw syscall. >=20 > Release of glibc 2.34 added _Fork(), do the same for FreeBSD. > Clarify threading behavior for fork() in the manpage. >=20 > Reviewed by: markj > Sponsored by: The FreeBSD Foundation > MFC after: 2 weeks > Differential revision: https://reviews.freebsd.org/D31378 This breaks the build on case-insensitive filesystems like macOS has, since _Fork.o for this C file and _fork.o for __sys_fork and _fork conflict, leading to either build failures (because _fork.o gets replaced and __sys_fork is undefined) or silently not including _Fork (because _Fork.o gets replaced) in the library, with it being non-deterministic based on whichever order the files happen to be built in, and potentially varying between the three different libraries as the .o, .pico and .nossppico files are independent. Jess
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42166E5E-A749-4FC7-A834-8A35D58706EF>