From owner-freebsd-hackers Tue Apr 22 18:15:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA22616 for hackers-outgoing; Tue, 22 Apr 1997 18:15:31 -0700 (PDT) Received: from inf.enst.fr (DhS0De5qwDjIixqH6vPbR8Dy+s7gmYZi@inf.enst.fr [137.194.2.81]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA22608 for ; Tue, 22 Apr 1997 18:15:26 -0700 (PDT) Received: from email.enst.fr (email.enst.fr [137.194.168.17]) by inf.enst.fr (8.8.4/8.8.4) with ESMTP id DAA16018; Wed, 23 Apr 1997 03:11:13 +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 DAA19871; Wed, 23 Apr 1997 03:09:40 +0200 (MET DST) Received: (from fenyo@localhost) by nikopol.enst.fr (8.8.4/8.8.4) id DAA21251; Wed, 23 Apr 1997 03:09:38 +0200 (MET DST) To: Terry Lambert Cc: freebsd-hackers@FreeBSD.org, 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 Subject: Re: fd locking problem with libc_r ? References: <199704222354.QAA27858@phaeton.artisoft.com> From: fenyo@email.enst.fr (Alex Fenyo (eowyn)) Date: 23 Apr 1997 03:09:23 +0200 In-Reply-To: Terry Lambert's message of Tue, 22 Apr 1997 16:54:37 -0700 (MST) Message-ID: Lines: 27 X-Mailer: Red Gnus v0.50/XEmacs 19.14 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert writes: > It's because only one blocking operation can be outstanding on an > FD at a time in a user space threading implementation. But then, I have two questions : .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...). Sincerly, Alexandre Fenyo