This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [MTASCsft PATCH 30/??] MT-, AS- and AC-Safety docs: manual/stdio.texi
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: codonell at redhat dot com, libc-alpha at sourceware dot org
- Date: Sat, 01 Feb 2014 01:14:47 -0200
- Subject: Re: [MTASCsft PATCH 30/??] MT-, AS- and AC-Safety docs: manual/stdio.texi
- Authentication-results: sourceware.org; auth=none
- References: <ortxelb5zd dot fsf at livre dot home> <or4n4uoncj dot fsf at livre dot home> <ord2jcg40v dot fsf_-_ at livre dot home> <52EC57B4 dot 4000306 at redhat dot com>
On Feb 1, 2014, "Carlos O'Donell" <carlos@redhat.com> wrote:
> On 01/27/2014 10:48 PM, Alexandre Oliva wrote:
>> There are two issues covered in this patch that I'm not so sure about:
>>
>> - _unlocked functions that take a stream are not marked as unsafe,
>> because it is users' responsibility to assure proper synchronization
>> over objects named as arguments. But how about _unlocked functions that
>> don't take a stream as an argument, such as those that implicitly use
>> stdin or stdout? I decided to mark them with @mtasurace{:stdin} or
>> @mtasurace{:stdout}, rather than @mtsrace{:stream}, because the streams
>> are not named as arguments. However, I could be convinced to stick with
>> @mtsrace since the stream is effectively chosen by the user, by choosing
>> these convenience functions rather than those that take the stream
>> explicitly. Thoughts?
> I like @mtasurace{:stdout}. You can use it to group with any other functions
> that are touching stdout and that gives the user hints about the interaction
> between those functions.
The question really was about whether to use @mtasurace or @mtsrace with
:stdout. Either marker would offer the same hint; the different is
whether the implied stream would be regarded as chosen internally by the
library (thus @mtasurace like any static buffer), or chosen by the user
even if not explicitly named (thus @mtsrace like any user-supplied
opaque variable).
>> - the other point of contention is whether such trivial functions as
>> feof_unlocked should even get an @mtsrace{} mark, considering that all
>> they do is test a single bit from a single word in the stream. It's not
>> like the access is safe under posix synchronization requirements, but
>> the library needs not abide by them, and nothing can really go wrong
>> unless some other undefined behavior was invoked (say, a concurrent
>> fclose that could cause the access to read from free()d memory)
> It's an _unlocked function and thus the user must ensure that the stream
> is not manipulated outside of the function. Thus it has no marker.
> We discuss this already in intro.texi, that if the user is responsible
> for the synchronization of the object then it doesn't get a marker.
That's not quite what I understood we agreed on. The current docs say
they just aren't regarded as unsafe, but opaque types do get an @mtsrace
marker so that the user is reminded of what to guard on.
> OK to checkin.
I'm going ahead and checking this in because I believe we are in
agreement here; if we aren't, we can revise it in a subsequent patch.
> It's a shame prtinf isn't AS-safe as is expected by many users who
> use printf in a signal handler. How unsafe is it's use in a signal
> handler really?
printf doesn't call malloc very often, and it wouldn't be too hard to
make malloc AS-Safe, so the @acsuheap is not a big deal. @asucorrupt,
however, is: stdout may be in a partially-updated state when interrupted
by a signal, and then calling printf (or any other output function) will
misbehave. I haven't thought much about how to make stream updates
sufficiently safe to avoid this problem.
This is not a more frequent problem throughout the library because most
internal data structures are guarded by non-recursive locks, so the get
@asulock instead. When the lock is recursive, like in streams, we don't
self-deadlock, so the potential corruption becomes the problem (not to
mention that recursive locks seem to be AS-Unsafe too).
--
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