This is the mail archive of the 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] fclose should lock stream first to synchronize with funlockfile

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
            Summary|deadlock between freopen    |fclose should lock stream
                   |and fclose                  |first to synchronize with
                   |                            |funlockfile

--- Comment #16 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Andreas Schwab from comment #14)
> That's a good point.  In that case unlinking before locking is not valid, I
> think.  The comparison with free does not fit here, because you cannot lock
> memory blocks.

To be clear this bug is reopened because fclose *should* take the lock early to
wait for any other funlockfile to complete before it does any other work?

So while the original reason for this bug is invalid, we have another reason to
keep it around.

I've adjusted the title. Please correct this if I misunderstood.

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]