This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: thread safety level of fwide
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Torvald Riegel <triegel at redhat dot com>, MaShimiao <mashimiao dot fnst at cn dot fujitsu dot com>, "Carlos O'Donell" <carlos at redhat dot com>, libc-help at sourceware dot org, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Fri, 21 Nov 2014 12:04:48 -0200
- Subject: Re: thread safety level of fwide
- Authentication-results: sourceware.org; auth=none
- References: <546C4388 dot 1090209 at cn dot fujitsu dot com> <or61eborsv dot fsf at free dot home> <1416488347 dot 1771 dot 26 dot camel at triegel dot csb> <20141121041036 dot GU22465 at brightrain dot aerifal dot cx>
On Nov 21, 2014, Rich Felker <dalias@libc.org> wrote:
> As a function that operates on a FILE, fwide is required by POSIX to
> behave as if it acquires the internal recursive mutex on the target
> file.
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/flockfile.html
Interesting... This indeed appears to rule out the optimization of
testing for safe values instead of taking a lock. It's not like we can
just assume unordered access is acceptable: flockfile/funlockfile does
force a global total order, and (as you said) they bring memory acquire
and release with them.
This means we have a bug in at least fwide and fileno.
I wonder if addmntent is also covered by this requirement: with the
current implementation, it takes and releases the stream's lock twice.
--
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 Brasil GNU Toolchain Engineer