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 30/??] MT-, AS- and AC-Safety docs: manual/stdio.texi


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


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