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: Florian Weimer <fweimer at redhat dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 17 Nov 2015 15:14:07 -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> <564B48D2 dot 5090002 at redhat dot com> <564B497F dot 4070002 at redhat dot com>
On 11/17/2015 10:36 AM, Florian Weimer wrote:
> On 11/17/2015 04:33 PM, Carlos O'Donell wrote:
>
>> 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.
>
> Other libraries may encounter this problem, too, because they have
> separate sets of locks and no longer achieve mutual exclusion. For
> example, in-process databases such as SQLite which implement new-style,
> file-private locks in an emulation layer will break.
I don't see any file-private lock implementation in SQLite upstream,
but you are correct from a first principles perspective.
Could you explain in a little more detail how you see the failure
mode in this case?
Cheers,
Carlos.