This is the mail archive of the libc-help@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: thread safety level of fwide


On 11/19/2014 03:32 PM, Alexandre Oliva wrote:
> On Nov 19, 2014, MaShimiao <mashimiao.fnst@cn.fujitsu.com> wrote:
> 
>> After reading it's source code, I think it should be marked with race:stream.
>> The reasoning is fwide() uses fp several times inside without holding the lock over all of them.
> 
>> How do you think about that?
> 
> The uses of fp, although technically racy, are well-defined, because of
> the way stream orientation works: once it's decided, it never changes,
> so it is safe to test, before taking a lock, whether it is already
> decided and use the settled value if so.  It is only if it is not
> decided yet (when _mode is zero) and we want to set a value (when mode
> is nonzero) that we have to resort to mutual exclusion to serialize mode
> settings.
> 
> Torvald, this is another of those âtechnically a race, but arguably
> safeâ cases that you've been looking for in glibc.  This idiom of using
> âundecidedâ initial values tested before taking locks is quite common in
> IOstreams, in TLS infrastructure, and in various __have_*
> feature-testing caches throughout glibc.

Do we ignore the race against fclose?

In manual/stdio.texi we have:

comment stdio.h
@comment ISO
@deftypefun int fclose (FILE *@var{stream})
@safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{} @asulock{}}@acunsafe{@aculock{} @acsmem{} @acsfd{}}}
@c After fclose, it is undefined behavior to use the stream it points
@c to.  Therefore, one must only call fclose when the stream is
@c otherwise unused.  Concurrent uses started before will complete
@c successfully because of the lock, which makes it MT-Safe.  Calling it
@c from a signal handler is perfectly safe if the stream is known to be
@c no longer used, which is a precondition for fclose to be safe in the
@c first place; since this is no further requirement, fclose is safe for
@c use in async signals too.  After calling fclose, you can no longer
@c use the stream, not even to fclose it again, so its memory and file
@c descriptor may leak if fclose is canceled before @c releasing them.
@c That the stream must be unused and it becomes unused after the call
@c is what would enable fclose to be AS- and AC-Safe while freopen
@c isn't.  However, because of the possibility of leaving __gconv_lock
@c taken upon cancellation, AC-Safety is lost.

I highlight: "Concurrent uses started before will complete successfully
because of the lock, which makes it MT-Safe."

Is that still true if we access members of FILE* outside of the lock?

Cheers,
Carlos.


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