Date: Thu, 22 Feb 2001 20:59:13 -0800 (PST) From: Brian Feldman <green@FreeBSD.org> To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/lib/libc/stdio _flock_stub.c Message-ID: <200102230459.f1N4xE197992@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
green 2001/02/22 20:59:13 PST
Modified files:
lib/libc/stdio _flock_stub.c
Log:
Fix the problems I (and others, undoubtedly) have been having for a
while with threaded software in -CURRENT acting very "weird". It has
seemed, for example, in Mozilla that threads attempting to do host
lookups have been locking up. That's exactly the case.
There was a race condition in the implementation of the initialization
of the mutex used to protect FILE operations, first of all: multiple
instances of FLOCKFILE() in libc could occur on the same FILE at
the same time and cause strange behavior by overwriting eachothers'
creation of the mutex and the rest of the file lock.
Secondly, it's not appropriate to test the "validity" of the file
descriptor referenced by the FILE; if the code is calling FLOCKFILE()
or FUNLOCKFILE(), it wants the FILE to be locked or unlocked, not
to be locked or unlocked on the condition that _file is >= 0. This
also could quite easily cause leaks by failing to perform the lock or
unlock operation when it actually is needed.
Mozilla now works again on -CURRENT when linked to libc_r.so.5 and
libc.so.5.
Revision Changes Path
1.7 +13 -4 src/lib/libc/stdio/_flock_stub.c
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102230459.f1N4xE197992>