From owner-freebsd-current Thu Sep 9 10:59:45 1999 Delivered-To: freebsd-current@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id ABD6F15709 for ; Thu, 9 Sep 1999 10:59:38 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id KAA11324; Thu, 9 Sep 1999 10:58:40 -0700 (PDT) Date: Thu, 9 Sep 1999 10:58:39 -0700 (PDT) From: Julian Elischer To: Luigi Rizzo Cc: current@FreeBSD.ORG Subject: Re: An FS question perhaps... non blocking I/O. In-Reply-To: <199909091418.QAA05520@labinfo.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The Posix AIO calls that john implememted are the best way of doing this. On Thu, 9 Sep 1999, Luigi Rizzo wrote: > Hi, > > please redirect to the appropriate forum if appropriate. > > There is one thing i don't completely understand with non-blocking > FS operation. > > Is there any way to guarantee (more or less strictly, see below) > that when i issue a read() on a file (a real file coming from a > UFS i mean) such read will not block because data from the disk is > not in memory yet, yet avoid that i end up in a busy loop. > > The app i have in mind is squid-like, which, if i understand well, is a > single process looping around a select. If i get things right, select() > on a file descriptor will return the read bit set if i am not at the > end of file, yet the block might not be in memory yet even if the UFS > seems to do readahead. Maybe i can turn NONBLOCK on for these > descriptors, but still would have select returning essentially useless > info as I'd need to try the read() to be sure... > > Maybe poll() has some way to indicate "yes you can read and the page is > in memory" ? I can tolerate some occasional failures when because of > memory shortage the readahead page is discarded after the select/poll > in favour of some other one... > > Any suggestion ? Would async I/O help in a case like this, considering > the possible overhead for handling signals when a transfer is > complete ? > > thanks > luigi > -----------------------------------+------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) > > http://www.iet.unipi.it/~luigi/ngc99/ > ==== First International Workshop on Networked Group Communication ==== > -----------------------------------+------------------------------------- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message