From owner-freebsd-current Tue Sep 5 13:44:54 2000 Delivered-To: freebsd-current@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id B0A9C37B423 for ; Tue, 5 Sep 2000 13:44:48 -0700 (PDT) Received: (from ache@localhost) by nagual.pp.ru (8.11.0/8.11.0) id e85KiYi72367; Wed, 6 Sep 2000 00:44:34 +0400 (MSD) (envelope-from ache) Date: Wed, 6 Sep 2000 00:44:33 +0400 From: "Andrey A. Chernov" To: Bruce Evans Cc: Peter van Dijk , current@freebsd.org Subject: Re: FIFOs & select: what about our implementation? Message-ID: <20000906004433.A72273@nagual.pp.ru> References: <20000905192458.A1428@dataloss.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bde@zeta.org.au on Wed, Sep 06, 2000 at 07:35:50AM +1100 Organization: Biomechanoid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Sep 06, 2000 at 07:35:50AM +1100, Bruce Evans wrote: > This behaviour is sort of intentional. Reads on a named pipe with no > writers are specified by POSIX.1 to return immediately. 4.4BSD does > extra work to break this in some cases. select() on a read descriptor > open on such a pipe just follows read(). I think it started giving > the behaviour that you don't want when I fixed read(). Please consider that we talk not about reads but about select. 'Select' is used to indicate that data is available while 'read' used to read it, they are two different things and behaviour of one thing not related to other. Currently select indicates that data is available when it really isn't. I don't ask to fix current read implementation, but select is just unusable for FIFOs in its current form. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message