This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: question about race:stream in glibc manual
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: MaShimiao <mashimiao dot fnst at cn dot fujitsu dot com>
- Cc: Alexandre Oliva <aoliva at redhat dot com>, carlos at systemhalted dot org, libc-help at sourceware dot org
- Date: Tue, 18 Nov 2014 22:52:47 -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> <546BFF1C dot 5000704 at redhat dot com> <546C0D67 dot 4000106 at cn dot fujitsu dot com>
On 11/18/2014 10:24 PM, MaShimiao wrote:
>> 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.
> May I express my opinion?
You may :-)
> I'm not sure whether addmntent's target is working safely in multi-thread or not
> But if not, I think regarding it as a bug is not exactly appropriate.
> In single thread, addmntent can work safely.
> Just as API contract, Structure can be written at the end of the open file fp correctly.
> That's my own opinion.
My apologies, I now see that addmntent is not in POSIX, which means it doesn't
follow the normal MT-Safe requirement.
I agree it is not a bug for it to fail in an MT environment.
>>> 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?
> At 11/14/2014 04:26 PM UTC+8, I sent a patch to modify addmntent's mark from
> MT-Unsafe race:stream to MT-safe race:stream in the glibc manual.
I agree. MT-Safe race:stream is the best option.
Cheers,
Carlos.