Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 9 Sep 1999 16:18:57 +0200 (MET DST)
From:      Luigi Rizzo <luigi@labinfo.iet.unipi.it>
To:        current@freebsd.org
Subject:   An FS question perhaps... non blocking I/O.
Message-ID:  <199909091418.QAA05520@labinfo.iet.unipi.it>

next in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909091418.QAA05520>