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>, GNU C Library <libc-alpha at sourceware dot org>
- Cc: Florian Weimer <fweimer at redhat dot com>
- Date: Fri, 13 Nov 2015 22:27:29 -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>
On 11/10/2015 07:27 AM, Adhemerval Zanella wrote:
>> IIUC your work removes these variables as it introduces cancellation
>> regions around the syscalls, so we shouldn't see this problem?
>>
>> Does that sound right?
>
> Currently my patchset still adds the 'optimization' to first check if
> program is in single-thread to avoid call the cancellation function.
> This is done in sysdep-cancel.h headers.
OK, if we don't remove the optimization then there is still the risk
that a statically dlopen'd libc.so.6 may think it is unthreaded,
and a dlmopen'd libc.so.6 may think it is unthreaded.
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.
Does that make sense?
Cheers,
Carlos.