This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Cancellation and dlmopen?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 17 Nov 2015 10:33:38 -0500
- 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> <564B3400 dot 9060805 at linaro dot org>
On 11/17/2015 09:04 AM, Adhemerval Zanella wrote:
>
>
> 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.
Or document that if the new namespace does not create any threads of it's
own that the namespace is *not* thread safe. So calls from non-namespace
created threads into the namespace are not safe.
Cheers,
Carlos.