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 WIP6 01/33] MT-, AS- and AC-Safety docs


On 01/23/2014 07:53 AM, Alexandre Oliva wrote:
> On Jan 22, 2014, "Carlos O'Donell" <carlos@redhat.com> wrote:
> 
>> That's fine except that `@item\nText' still gives a bullet without any
>> text beside it and that confusingly looks like missing text.
>  
> Err...  After the initial change, I see text right next to the bullets
> in info, pdf and html outputs.  Do you still see stand-alone bullets?
 
I do not. Your version is correct.
 
>>> Some clarity, I think.  Instead of having to define each instance of
>>> âidâ, we'd have a general pattern governing all such âidâs, wherein
>>> race:id would suggest the need for an exclusive/write lock to make the
>>> function safe, whereas ro:id would indicate âidâ is expected to be
>>> read-only, but if any modifiers are called (while holding an exclusive
>>> lock), then ro:id-marked functions ought to be guarded with a read lock
>>> for safe operation.  ro:env or ro:locale, for example, seems to convey
>>> more clearly the expectations and the meaning, than just env or locale.
> 
>> Add this to the comment :-)
>  
> Done
 
Thanks.
 
>>> Functions that allocate or deallocate file descriptors will generally be
>>> marked as such.  Even if they attempted to protect the file descriptor
>>> allocation and deallocation with cleanup regions, allocating a new
>>> descriptor and storing its number where the cleanup region could release
>>> it cannot be performed as a single atomic operation.  Similarly,
>>> releasing the descriptor and taking it out of the data structure
>>> normally responsible for releasing it cannot be performed atomically.
>>> There will always be a window in which the descriptor cannot be released
>>> because it was not stored in the cleanup handler argument yet, or in
>>> which it was already taken out before releasing it in the normal flow.
> 
>> s/in which//g
> 
> Please confirm â...window the descriptor...â; it doesn't seem to parse
> correctly to me.
 
Bad regex.

Suggest last sentence:

There will always be a window in which the descriptor cannot be released
because it was not stored in the cleanup handler argument yet, or it was
already taken out before releasing it in the normal flow.

I didn't notice there were two "in which" in that sentence :-)
 
>> I like "!posix" :-)
>  
> You got it ;-)
> 

Thanks!

Cheers,
Carlos.


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