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: Alexandre Oliva <aoliva at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Torvald Riegel <triegel at redhat dot com>, KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, Rich Felker <dalias at aerifal dot cx>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Fri, 31 May 2013 17:51:15 -0300
- Subject: Re: Thread-, Signal- and Cancellation-safety documentation
- References: <orppym7okv dot fsf at livre dot home> <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>
On May 31, 2013, Florian Weimer <fweimer@redhat.com> wrote:
> There's no fgetxattrat, so it is tempting to emulate the missing
> opportunity to specify AT_SYMLINK_NOFOLLOW using chdir and
> lgetxattr. If you do this in library code, it is not thread-safe at
> all, even though you only use functions which are defined as
> thread-safe.
I'm not sure it doesn't qualify as thread safe, but it's definitely
something that ought to be noted in the documentation, just like (in my
local tree) nftw has a note about its calls to chdir() if you call it
with FTW_CHDIR.
I don't see any support from the relevant standards to label either of
them as not thread safe. I do, however, agree that there's another
relevant safety property there; shall we call it cwd-unsafe?
>> 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!
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer