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: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Florian Weimer <fweimer 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: Fri, 31 May 2013 22:59:34 -0400
- Subject: Re: Thread-, Signal- and Cancellation-safety documentation
- References: <20130326064347 dot GL20323 at brightrain dot aerifal dot cx> <515AB073 dot 9000500 at redhat dot com> <20130402134325 dot GO20323 at brightrain dot aerifal dot cx> <CAHGf_=q=2sM0C5kLazsVWiRfRvO0NX-sDRX2-SfoJkkCix9vzQ at mail dot gmail dot com> <1368788825 dot 3054 dot 3182 dot camel at triegel dot csb> <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>
On Fri, May 31, 2013 at 05:51:15PM -0300, Alexandre Oliva wrote:
> >> Sure, if two threads call it concurrently, you can't predict which one
> >> ends up as the cwd for the process, but that's just as impredictable as
> >> the result when two threads call write concurrently, or rename
> >> concurrently from or to the same pathname. But you wouldn't say
> >> multi-threaded programs shouldn't call write or rename, would you?
>
> > That's because the immediate caller can ensure that it has exclusive
> > access to the resource (or determine that the race is benign),
>
> Huh? How could anyone ensure it has exclusive access to a filename
> that's about to be renamed, or overwritten by a rename? That's not even
> something that could be guaranteed even involving all the threads of a
> process: other processes could mess with the files!
If the directory has a 255-character random name and is located in a
non-readable directory owned by root on a system where no process has
retained root, then you can be quite certain that only the process(es)
which have the name of the directory or a live file descriptor for it
can perform a rename in it.
Extreme examples aside, if an application is working in a working
directory that (by contract/convention) belongs to it, and which has
the right permissions so that other users cannot mess with it, and the
application has documented that the user running the application
cannot mess with the contents of this directory while the application
is running without invoking UB, then you have a reasonable real-world
situation where exclusivity is "guaranteed".
Rich