19 Aug
2016
19 Aug
'16
7:46 p.m.
Hi Thomas,
Thomas Petazzoni wrote,
Hello,
On Fri, 19 Aug 2016 14:03:45 -0400, Rich Felker wrote:
Removing the visibility of the pthread_mutex_* dummies would be the
best, so that dynamic linking is failing, when -lpthread is
missing.
Isn't it like with librt? Usually you use -lrt when using any
advanced realtime functions from the C library.
And any tutorial you find with your favourite internet search engine
mentions to use -lpthread or -pthread when linking an application
which uses pthread.h.
So who is actually to blame for this situation that application
programmers try to use pthread.h without linking libpthread? :)
http://linux.die.net/man/7/pthreads
"On Linux, programs that use the Pthreads API should be compiled
using cc -pthread."
best regards
Waldemar
If they want to keep taking advantage of the
nop-out hack for dynamic
linking glibc, a suitable solution would be a configure check
something like:
checking whether -larchive needs -lpthread... yes
That's a whole lot of work in potentially numerous upstream packages :-/
Also, there's still the odd thing that with uClibc, linking an
application using pthread_mutex_lock/unlock with just libc works fine
when dynamic linking, but not when static linking.
If the decision is indeed that there is no fallback implementation in
libc, then there shouldn't be any fallback implementation, regardless
of whether we're static linking or not.
However, I'm not sure glibc will even be
keeping this behavior
long-term, as it's silent-error-prone. Some programmers have been very
unpleasantly surprised to find out that the dummy lock functions in
glibc's libc.{so,a} don't even enforce any exclusion. I believe this
was visible in trylock succeeding on an already-locked mutex where it
should have failed. I just did a quick search to see if I could find
this discussion on the bug tracker but I didn't find it; it might be
on the mailing list or somewhere else, or just buried somewhere that's
hard to search.
Note that because there exist process-shared mutexes, the dummy
implementation is actually unsafe. An application might omit linking
-lpthread because it sees that it links fine without it, but then mmap
some shared memory and use pthread_mutex_lock for inter-process
synchronization. Very bad silent breakage then happens.
Indeed.
IMO the right fix is not to link a dummy
implementation but instead to
have the real implementation provide fast-paths for (!multi_threaded
&& !process_shared) cases.
OK, makes sense.
Waldemar, how do you see things moving forward in uClibc? Removing the
fallback implementation entirely?