Hello,
On Fri, 19 Aug 2016 14:03:45 -0400, Rich Felker wrote:
> 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?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
_______________________________________________
devel mailing list
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
