This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [MTASCsft PATCH 10/??] MT-, AS- and AC-Safety docs: manual/filesys.texi


On Jan 30, 2014, "Carlos O'Donell" <carlos@redhat.com> wrote:

> On 01/24/2014 10:29 AM, Alexandre Oliva wrote:
>> Some of the functions in this file had @mtsrace (previously xguargs)
>> because they'd misbehave should the pathnames passed to them as strings
>> be modified concurrently.  I've dropped those from this patch.

> Right, I assume you did that because we require users to take care
> that those paths as strings are race free.

Yup

>> Other occurrences of @mtsrace had to do with non-atomic uses of timeval
>> or utimbuf objects passed as arguments; those are not opaque types, so
>> I've dropped the race annotations from them too.

> Same as above.

Ditto

>> The one oddity in this patch is the @mtasurace{:dirstream} annotation in
>> readdir and readdir64.  These functions, instead of using static
>> buffers, they return pointers into the internal buffers in the DIR
>> objects they take as arguments.  They are MT-Unsafe because the returned
>> object is not safe to use without coordinating with other uses of
>> dirstream, but someone might be surprised by the lack of mentioning a
>> race on an internal buffer, and by the allegation of a race involving
>> the dirstream object, in spite of its being guarded by internal locks.
>> I've considered using say @mtasurace{:dirstream.buf}, but in the end I
>> decided I'd stick with @mtasurace{:dirstream} and ask whether others had
>> better ideas.  Anyone?

> I have no better idea :-)

> Patch OK to commit as long as /bsd doesn't render to anything.
 
Uhh, serious?  :-(  Later files (signal.texi comes to mind) have plenty
of these, and because on different systems different functions are
implemented in terms of different primitives, we get to different
conclusions depending on whether we take note of kernel-specific safety
issues.

So, if we really want to drop the conditionals, should I do that by
simply removing them, or by introducing a wrapper macro (say @sftcond{})
that discards its argument?

-- 
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 Brazil Toolchain Engineer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]