From owner-freebsd-hackers Tue Apr 22 16:08:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA14331 for hackers-outgoing; Tue, 22 Apr 1997 16:08:33 -0700 (PDT) Received: from enst.enst.fr (MteLXQDnUQ6XPsfTfKJgea27Se3xnxSg@enst.enst.fr [137.194.2.16]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA14325 for ; Tue, 22 Apr 1997 16:08:28 -0700 (PDT) Received: from email.enst.fr (email.enst.fr [137.194.168.17]) by enst.enst.fr (8.8.4/8.8.4) with ESMTP id BAA24786; Wed, 23 Apr 1997 01:08:21 +0200 (MET DST) Received: from nikopol.enst.fr (nikopol.enst.fr [137.194.168.105]) by email.enst.fr (8.8.4/8.8.4) with ESMTP id BAA18450; Wed, 23 Apr 1997 01:08:08 +0200 (MET DST) Received: (from fenyo@localhost) by nikopol.enst.fr (8.8.4/8.8.4) id BAA20563; Wed, 23 Apr 1997 01:08:06 +0200 (MET DST) Date: Wed, 23 Apr 1997 01:08:06 +0200 (MET DST) Message-Id: <199704222308.BAA20563@nikopol.enst.fr> From: "Alex Fenyo (eowyn)" To: freebsd-hackers@freebsd.org Subject: fd locking problem with libc_r ? Cc: jb@cimlogic.com.au X-WWW: http://home.eowyn.fr.eu.org/~fenyo/documents/axel.html X-PGP-Key: finger alex@eowyn.fr.eu.org X-NIC-Handle: AF713 X-Whois: whois -h whois.internic.net fenyo X-Pager: 06-04-30-75-94 (for emergency only) Organization: Ecole Nationale Superieure des Telecommunications de Paris Reply-to: fenyo@email.enst.fr Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, I encountered a possibly bug in libc_r. Suppose you have 2 threads and a file descriptor, for instance a socket. Suppose too that nothing is to be read on the fd (the daemon on the other side didn't feed the socket), but we can write on it (the daemon on the other side reads on it). The first thread performs a call to read() on fd. LATER, the second thread performs a call to write() on the fd. The problem is that : the write call in the second thread will always be performed after something can be read by the first thread. It's because in src/lib/libc_r uthread_write.c, there is a read-write lock on the fd : ------------------------------------------------------------ if ((ret = _thread_fd_lock(fd, FD_RDWR, NULL, __FILE__, __LINE__)) == 0) { ------------------------------------------------------------ I wonder why is there such a read-write lock when just a write lock would be sufficient (and would solve the problem) ??? Perhaps it's because a write lock wouldn't be sufficient ??? (I can't find a reason for that ?) The problem is the same with writev(). Many thanks, Alexandre Fenyo