This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Cancellation and dlmopen?
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Carlos O'Donell" <carlos 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 21:21:16 +0100
- 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> <564B8A8F dot 9060708 at redhat dot com>
On 11/17/2015 09:14 PM, Carlos O'Donell wrote:
> I don't see any file-private lock implementation in SQLite upstream,
> but you are correct from a first principles perspective.
See os_unix.c, section âPosix Advisory Lockingâ. The global variable is
called inodeList.
> Could you explain in a little more detail how you see the failure
> mode in this case?
Two copies of libsqlite3.so in the same process will have separate
inodeList values. This means that they can both lock the same file and
assume they have exclusive access. In addition, if one SQLite copy
closes this file, it releases the lock for all the other files. SQLite
needs to keep global state because POSIX advisory locks are âbroken by
designâ (their words, not mine, but it is difficult to see a scenario in
which the POSIX semantics make any sense at all), and if the state is
namespace-local instead of global, things fall apart quickly.
Florian