Re: lib/59137: pthread_atfork deadlocks if called in atfork handler

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR lib/59137; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: lib/59137: pthread_atfork deadlocks if called in atfork handler
Date: Thu, 06 Mar 2025 06:27:08 +0700

     Date:        Wed,  5 Mar 2025 21:00:01 +0000 (UTC)
     From:        campbell+netbsd%mumble.net@localhost
     Message-ID:  <20250305210001.955531A923F%mollari.NetBSD.org@localhost>
 
 
   | POSIX is fuzzy on the semantics (and hints that pthread_atfork
   | is destined for the dustbin of history):
 
 Yes, it will probably be removed in the next major edition, Issue 9,
 but I'd guess that's something of the order of a decade or more away.
 In the meantime we are stuck with it.  It might be (ie: is) marked as
 Obsolete, but it is still part of the standard (but no-one is likely
 to spend much, or any, effort in fixing or adding stuff).
 
   | NetBSD's libpthread currently deadlocks in this case,
 
 Yes, it would.    However I see no reason the lock is necessary while
 running the handlers, or if one would seem to be a good idea to prevent
 any being run in parallel in case of multiple threads all deciding to
 fork at the same time, then use a different lock for running the things
 than is used for creating them (and forking()).
 
   | It could fail with EDEADLK,  although the only failure POSIX
   | enumerates for pthread_atfork is ENOMEM.
 
 That would be OK, generating other errors than those listed is
 generally OK, as long as the error (errno) generated in the cases
 listed is the one specified.   If there's a new/different error
 condition (which this would be) a different errno is appropriate,
 and allowed (provided it isn't generated in a case POSIX says must
 work, and this one is not that I think).
 
   | >Fix:
   | Whether or not we decide to `fix' this (whether or not we consider
   | it a bug), we should at least write down the rationale for our choice
   | in a place that is easily findable, like this gnats bug database.
 
 I think it is a bug, libc functions should not cause processes to deadlock.
 But assuming we don't simply fix it, so nothing specific needs to be
 documented, the place to document it would be the manual page, which
 users can be expected to have read before using the interface (any of
 them) - not some in some random PR which will be forgotten completely
 soon after it is closed (even if it is referenced in the commit message,
 application code writers aren't expected to look through the commit logs
 to try and work out how to use something).
 
 kre