From owner-freebsd-hackers  Thu Apr 24 15:28:34 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id PAA05603
          for hackers-outgoing; Thu, 24 Apr 1997 15:28:34 -0700 (PDT)
Received: from werple.net.au (melb.werple.net.au [203.9.190.18])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA05575
          for <freebsd-hackers@freebsd.org>; Thu, 24 Apr 1997 15:28:30 -0700 (PDT)
Received: (qmail 29705 invoked by uid 5); 24 Apr 1997 22:28:27 -0000
Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.7.5/8.7.3) id IAA01941; Fri, 25 Apr 1997 08:00:01 +1000 (EST)
From: John Birrell <jb@cimlogic.com.au>
Message-Id: <199704242200.IAA01941@freebsd1.cimlogic.com.au>
Subject: Re: fd locking problem with libc_r ?
To: fenyo@email.enst.fr
Date: Fri, 25 Apr 1997 08:00:00 +1000 (EST)
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.4ME+ PL22 (25)]
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

[Sorry for the delay, it's been one of those weeks!]

Alex Fenyo wrote:
> 
> 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 ?)

I think you are right, the read and write locks are independent
and they only exist at all because of the need to do things non-blocking
in user-space.

This will be solved when rfork() can be used to thread a user process.
I'm not sure where John Dyson got to with this... Maybe the vfork()
problems got in the way. 8-(

> 
> The problem is the same with writev().

Yep.

> 
> Many thanks,
> Alexandre Fenyo
> 
> 
Regards,


-- 
John Birrell - jb@cimlogic.com.au; jb@netbsd.org; jb@freebsd.org
CIMlogic Pty Ltd, 119 Cecil Street, South Melbourne Vic 3205, Australia
Tel +61 3 9690 6900 Fax +61 3 9690 6650 Mob +61 418 353 137