This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Thread-, Signal- and Cancellation-safety documentation
- From: Rich Felker <dalias at aerifal dot cx>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Alexandre Oliva <aoliva at redhat dot com>, Torvald Riegel <triegel at redhat dot com>, KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Tue, 4 Jun 2013 10:19:45 -0400
- Subject: Re: Thread-, Signal- and Cancellation-safety documentation
- References: <ora9nrh1cz dot fsf at livre dot home> <51A328F0 dot 5020003 at redhat dot com> <ora9ncqlg4 dot fsf at livre dot home> <51A86363 dot 2000900 at redhat dot com> <orip1yq3ek dot fsf at livre dot home> <20130601025934 dot GJ20323 at brightrain dot aerifal dot cx> <or61xxi33w dot fsf at livre dot home> <20130602142028 dot GL20323 at brightrain dot aerifal dot cx> <orli6sh1ju dot fsf at livre dot home> <51ADE0D3 dot 3050102 at redhat dot com>
On Tue, Jun 04, 2013 at 02:42:59PM +0200, Florian Weimer wrote:
> On 06/02/2013 07:20 PM, Alexandre Oliva wrote:
> >Just like the other calls we mentioned before, when used in situations
> >that assume and require some form of exclusivity that the black box
> >library might break. Or can you somehow assure the black box library
> >won't call creat or rename or whatever in the dir that was supposed to
> >be exclusively used for something else, but can't equally assure it
> >won't call chdir?!?
>
> It's easy to create a separate sub-namespace in the file system,
> just by using a specific directory tree for a clearly-defined
> purpose. For applications like PostgreSQL, messing directly with
> files in their private data directories is like attaching to the
> process with ptrace and changing a few bits. All bets are off.
>
> With chdir, umask, signal masks etc., there is just no way to
> introduce a separate namespace in the same process (partly because
> we don't support the clone system call). This even applies to
The clone syscall is not needed; the unshare syscall will do. I don't
know whether it's part of glibc's interface contract for this to work,
but as far as I can tell, pthread_create and calling unshare in the
new thread is safe and usable with most if not all of the current
unshare flags.
> cooperative, carefully written libraries. They would probably use
> locking, but there is no single lock they could agree to acquire.
Agreed. The problem is lack of an agreed-upon lock. If that lock were
used as a write-lock around every instance of changing the current
directory and as a read lock around every operation that takes a
filename, that would of course solve the problem in a horrible,
non-concurrent-friendly way.
Rich