question about race:stream in glibc manual

MaShimiao mashimiao.fnst@cn.fujitsu.com
Wed Nov 19 03:25:00 GMT 2014


On 11/19/2014 10:23 AM, Carlos O'Donell wrote:
> On 11/18/2014 06:52 PM, Alexandre Oliva wrote:
>> On Nov 18, 2014, "Carlos O'Donell" <carlos@redhat.com> 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.
May I express my opinion?
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.
> 
>> 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.

Best regards
> 
> Cheers,
> Carlos.
>  
> 
> .
> 


-- 
Ma Shimiao
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)



More information about the Libc-help mailing list