This is the mail archive of the glibc-bugs@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]

[Bug libc/24963] deadlock between freopen and fclose


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.

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