From owner-freebsd-hackers Wed Apr 23 09:56:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA09818 for hackers-outgoing; Wed, 23 Apr 1997 09:56:10 -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 JAA09811 for ; Wed, 23 Apr 1997 09:56:02 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA29076; Wed, 23 Apr 1997 09:50:22 -0700 From: Terry Lambert Message-Id: <199704231650.JAA29076@phaeton.artisoft.com> Subject: Re: fd locking problem with libc_r ? To: fenyo@email.enst.fr (Alex Fenyo (eowyn)) Date: Wed, 23 Apr 1997 09:50:22 -0700 (MST) Cc: terry@lambert.org, freebsd-hackers@FreeBSD.org, jb@cimlogic.com.au In-Reply-To: from "Alex Fenyo (eowyn)" at Apr 23, 97 03:09:23 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 > .Why a select() waiting only to be able to write on a fd (select(nfds, > NULL, writefds, NULL, NULL)), and a read on the same descriptor > are allowed to be performed at the same time by libc_r ??? > (such a select adds only a write lock on the descriptor) > > .Do you think the behaviour I talked about is posix compliant ? (my > opinion is that it is not, because each time a thread blocks > on read, nobody can write (on the same fd); difficult to handle !!!) > > I agree with you that only one blocking operation can be done > at a time. But this is not a problem, because the two calls > are not really done : they are done one time, in a non blocking way, > then the two threads are discarded from the running queue, and > then _thread_kern_sched() makes a big select (most of the time > non blocking, if there is at least one thread in the running queue) > with fdsets that contain all the descriptors that threads > may wait on (by calls to select, read, write etc...). I really don't know if this is intentional, to ensure order of operation, or if it's just a side effect of the implementation. The operations map would have to be kept seperately for this to work; it's not impossible, and it's probably not correct the way things are, but it's not currently done. The threads stuff is originally out of MIT; they would either be interested in patches, or able to tell you why it must stay the way it is. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.