This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/24963] deadlock between freopen and fclose
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Tue, 24 Sep 2019 15:45:21 +0000
- Subject: [Bug libc/24963] deadlock between freopen and fclose
- Auto-submitted: auto-generated
- References: <bug-24963-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=24963
--- Comment #13 from Rich Felker <bugdal at aerifal dot cx> ---
> I think it would even be valid to remove the locking on fp from fclose.
It's not valid to remove the locking from fclose, because in some cases
synchronization is obervable. For example, thread A could open a FILE and
immediately call flockfile before making the FILE pointer visible to any other
thread, and only call funlockfile as the final operation on it. Under such a
usage pattern, calling fclose from thread B is valid as soon as any
synchronization operation makes the FILE pointer visible to thread B.
The same can arise without explicit locking, if the action of a stdio operation
makes it observable that the operation causing the implicit locking has already
produced side effects and thus already holds the lock (releasing the lock and
reacquiring it would not be allowed by the implementation because it would
violate atomicity requirements). I've written about this long ago in
http://ewontfix.com/8/.
Note that, while the original bug as reported has correctly been marked as
RESOLVED/INVALID, there may be a related bug with fflush(0) as noted in
comments #5 and #6.
--
You are receiving this mail because:
You are on the CC list for the bug.