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: Alexandre Oliva <aoliva at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 23 Jan 2014 10:53:04 -0200
- 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>
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?
>> 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
>> 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.
> I like "!posix" :-)
You got it ;-)
--
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