From owner-freebsd-hackers Tue Apr 22 16:57:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA17682 for hackers-outgoing; Tue, 22 Apr 1997 16:57:29 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id QAA17677 for ; Tue, 22 Apr 1997 16:57:26 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA27858; Tue, 22 Apr 1997 16:54:37 -0700 From: Terry Lambert Message-Id: <199704222354.QAA27858@phaeton.artisoft.com> Subject: Re: fd locking problem with libc_r ? To: fenyo@email.enst.fr Date: Tue, 22 Apr 1997 16:54:37 -0700 (MST) Cc: freebsd-hackers@FreeBSD.org, jb@cimlogic.com.au In-Reply-To: <199704222308.BAA20563@nikopol.enst.fr> from "Alex Fenyo" at Apr 23, 97 01:08:06 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Suppose you have 2 threads and a file descriptor, for instance a socket. [ ... ] > 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 ?) It's because only one blocking operation can be outstanding on an FD at a time in a user space threading implementation. Look at it as if it were an operation queueing interface, and there was a single queue for servicing both reads and writes (VMS and many UNIX multidrop board drivers have exactly thjis restriction on their non-threaded I/O!). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.