Date: Sat, 31 Aug 2019 11:52:36 +0000 From: bugzilla-noreply@freebsd.org To: threads@FreeBSD.org Subject: [Bug 150959] [libc] Stub pthread_once in libc should call _libc_once Message-ID: <bug-150959-13406-pKBxbZEr5B@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-150959-13406@https.bugs.freebsd.org/bugzilla/> References: <bug-150959-13406@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=150959 andrew@tao11.riddles.org.uk changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew@tao11.riddles.org.uk --- Comment #5 from andrew@tao11.riddles.org.uk --- The current stub implementation of pthread_once now fails with an error return, which does not seem much of an improvement. In particular, it causes code that is static-linked with openssl to segfault unless libthr is linked into the process (the fact that openssl has inadequate error checks is a separate issue). I've been told in another bug thread that the only reason to have pthread stubs at all is to allow for libraries that might be dynamically loaded into either a threaded or unthreaded process. It seems to me that such libraries would be very likely to want to use pthread_once, and very unlikely to be able to cope with it failing (it has no normal reason to fail). Accordingly, libc should provide either a pthread_once stub that actually works (interoperably with the real implementation in case libthr gets pulled in later), or it should not provide the symbol at all, forcing libraries that want to use it to pull in libthr themselves. see also https://twitter.com/RhodiumToad/status/1165523338481061888 -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-150959-13406-pKBxbZEr5B>