This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [MTASCsft PATCH WIP6 01/33] MT-, AS- and AC-Safety docs
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 23 Jan 2014 11:24:36 -0500
- Subject: Re: [MTASCsft PATCH WIP6 01/33] MT-, AS- and AC-Safety docs
- Authentication-results: sourceware.org; auth=none
- References: <ortxelb5zd dot fsf at livre dot home> <52D6162F dot 50204 at redhat dot com> <ork3dzh36r dot fsf at livre dot home> <52E0241A dot 1020805 at redhat dot com> <or8uu6oo5r dot fsf at livre dot home>
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.