From b07bfac2ade9af2fcad138d2abc8eedc1d4be44e Mon Sep 17 00:00:00 2001
From: joerg <joerg@FreeBSD.org>
Date: Tue, 7 Oct 1997 07:24:50 +0000
Subject: Remove the claim that UUCP locking were not atomic.  It is since
 revision 1.8 of uucplock.c.

---
 lib/libutil/uucplock.3 | 14 +-------------
 1 file changed, 1 insertion(+), 13 deletions(-)

(limited to 'lib')

diff --git a/lib/libutil/uucplock.3 b/lib/libutil/uucplock.3
index c65e141..c920e4a 100644
--- a/lib/libutil/uucplock.3
+++ b/lib/libutil/uucplock.3
@@ -23,7 +23,7 @@
 .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
 .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 .\" 
-.\" $Id: uucplock.3,v 1.8 1997/08/10 18:42:38 ache Exp $
+.\" $Id: uucplock.3,v 1.9 1997/09/29 19:11:25 wosch Exp $
 .\" "
 .Dd March 30, 1997
 .Os
@@ -151,18 +151,6 @@ for further details.
 .Xr read 2 ,
 .Xr write 2
 .Sh BUGS
-Locking is not atomic.  Should a race condition occur, it's
-possible that the
-.Dq losing
-process fails to identify the
-.Dq winning
-process.  If this happens,
-.Fn uu_lock
-returns
-.Dv UU_LOCK_READ_ERR
-and errno is set to
-.Er EINVAL .
-.Pp
 It is possible that a stale lock is not recognised as such if a new
 processes is assigned the same processes id as the program that left
 the stale lock.
-- 
cgit v1.1