This is the mail archive of the
mailing list for the glibc project.
Re: question about race:stream in glibc manual
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Alexandre Oliva <aoliva 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:23:24 -0500
- 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> <or4mtwkqwv dot fsf at free dot home>
On 11/18/2014 06:52 PM, Alexandre Oliva wrote:
> 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.
IMO that's a bug. The API contract for addmntent requires the structure
be written at the end of the open file fp. It should lock the stream,
seek to the end, write, and unlock.
> 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.
I'm feeling very dense. What patch?