This is the mail archive of the
mailing list for the glibc project.
Re: question about race:stream in glibc manual
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: MaShimiao <mashimiao dot fnst at cn dot fujitsu dot com>, carlos at systemhalted dot org, libc-help at sourceware dot org
- Date: Tue, 18 Nov 2014 21:52:32 -0200
- Subject: Re: question about race:stream in glibc manual
- Authentication-results: sourceware.org; auth=none
- References: <54654BA4 dot 7020702 at cn dot fujitsu dot com> <546B7531 dot 7000305 at redhat dot com>
On Nov 18, 2014, "Carlos O'Donell" <firstname.lastname@example.org> wrote:
> On 11/13/2014 07:24 PM, MaShimiao wrote:
>> According to the manual, I think if a function has an argument FILE
>> *stream and the stream may cause data races inside the function, it
>> should annotated with MT-Safe race:stream. Am I right?
> You are not correct. The FILE* is an opaque object.
We experimented with distinguishing opaque and non-opaque objects for
some time, but in the end we decided not to make this distinction. In
the version we put in the manual, we state the user is responsible for
synchronization WRT all objects chosen by the user, but we explicitly
annotate functions with race:<parm> as a reminder, when opaqueness or
custom might suggest the library would take care of it.
addmntent is indeed MT-Safe, although there's a potential for unintended
behavior if the stream is repositioned between the seek and the write.
I said I wouldn't install the patch that fixes this if there were
objections by Tuesday. So now I'm gonna wait till I hear back from you
before I check it in. Please let me know.
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