On 06/10/2020 13:15, Nate Karstens via Libc-alpha wrote: > The fact that system(3) does not support pthread_atfork(3) also means > that it is not thread safe. See the discussion for the proposal of a > close-on-fork flag in the 2020 April and May timeframe, especially: > > https://lkml.org/lkml/2020/5/15/1067 > > Signed-off-by: Nate Karstens <nate.karstens@xxxxxxxxxx> Not sure if man pages characterizes file descriptor leak as mt-unsafe, at least we don't have this concept on glibc manual. In fact, I think adding a MT-Unsafe mark to this potentially make any libc call that is not atomic potentially MT-Unsafe, either when they do not concurrent trigger race issues regarding memory semantic. At least I think it should add a 'race' mark to indicate what exactly is MT-unsafe (as for other implementations). > --- > man3/system.3 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/man3/system.3 b/man3/system.3 > index aef40417a..8730fabd3 100644 > --- a/man3/system.3 > +++ b/man3/system.3 > @@ -127,7 +127,7 @@ l l l. > Interface Attribute Value > T{ > .BR system () > -T} Thread safety MT-Safe > +T} Thread safety MT-Unsafe > .TE > .SH CONFORMING TO > POSIX.1-2001, POSIX.1-2008, C89, C99. >
