This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Cancellation and dlmopen?
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Florian Weimer <fweimer at redhat dot com>, Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 17 Nov 2015 12:04:48 -0200
- Subject: Re: Cancellation and dlmopen?
- Authentication-results: sourceware.org; auth=none
- References: <56415059 dot 803 at redhat dot com> <5641E2A7 dot 9080406 at linaro dot org> <5646AA21 dot 4040003 at redhat dot com> <5646E51B dot 90501 at redhat dot com>
On 14-11-2015 05:39, Florian Weimer wrote:
> On 11/14/2015 04:27 AM, Carlos O'Donell wrote:
>
>> In both context's I think we will need to add something to the
>> documentation to clarify that if you are calling into an new namespace
>> (which is what dlopen from a static binary is equivalent to) that if the new
>> namespace does not also load libpthread.so, then it is not thread safe
>> for you to call any function in that new namespace from multiple
>> threads.
>
> But __libc_multiple_threads in the new namespace will still be zero even
> if libpthread.so is loaded, right? I don't think it is reasonable to
> expect applications to work around that. It needs knowledge of a lot of
> implementation details.
I am not really sure if the single-thread optimization for system calls
are really a gain in my new proposed cancellation mechanism. For current
approach I can see some gains, since cancellation syscalls required
2 functions calls which may add atomic operations. However on the
new approach is basically two functions calls with no atomic involved.
>
> Florian
>