On 04/08/15 08:10, Philip Guenther wrote:
On Tue, 7 Apr 2015, Martijn van Duren wrote:
I'm currently experimenting with weak symbols for a library that I want
to be thread safe without hard linking in the entire libpthread.
To test this I've set up the following code:
...
When compiling with pthread it seems it only resolves
pthread_mutex_init, but still uses the weak pthread_create and executes
secondary lock first:
...
Could someone please elaborate on what I'm doing wrong and how to implement
these weak symbols properly. Thank you in advance.
If the symbol is defined in the base executable, then it cannot be
overriden by a shared library, regardless of its binding (global or weak)
in the executable. Indeed, the reference will be resolved when the
executable is created, leaving no relocation dependent on the symbol
definition.
If you want to work with symbol interposition like this, you'll need to
actually build shared libraries.
Philip Guenther
Thank you, this seems to work.
I've also been looking at other ways to make this work, like by making a
custom cpthread_* function, which in turns loads pthread_create via
dlsym(RTLD_NEXT, "pthread_create") and test the output for NULL, which
also seems to work.
Could you inform me on the preferred way for making a library thread safe?
- always linking in lpthread into the library (which causes some extra
bloat in the loading of the extra library).
- making the required symbols available via weak symbols, as per my
original question. (which might not be very portable and might make the
code less transparent)
- making custom functions which load in the required symbols via dlsym
(which requires extra LoC)
- another method I haven't thought of?
To make my question even more concrete: I intend to lock a file with
flock, which isn't thread safe. Is there a (portable) way to lock a file
for both processes and threads alike, or should I construct a wrapper
with extra locking as per my question mentioned above?
Martijn van Duren
