From owner-freebsd-current Fri Sep 10 0:48:40 1999 Delivered-To: freebsd-current@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 84CBE153E1 for ; Fri, 10 Sep 1999 00:48:32 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id KAA90948; Fri, 10 Sep 1999 10:47:17 +0300 (EEST) (envelope-from will) To: Luigi Rizzo Cc: current@freebsd.org Subject: Re: An FS question perhaps... non blocking I/O. References: <199909091418.QAA05520@labinfo.iet.unipi.it.newsgate.clinet.fi> From: Ville-Pertti Keinonen Date: 10 Sep 1999 10:47:16 +0300 In-Reply-To: Luigi Rizzo's message of "9 Sep 1999 20:06:50 +0300" Message-ID: <86wvtzgqd6.fsf@not.demophon.com> Lines: 33 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Luigi Rizzo writes: > 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. There is no way to guarantee that a read will not block on disk I/O. The same applies to writes. The read/write calls should never return EAGAIN for local files, even if they are set for non-blocking I/O. This actually makes sense. Given virtual memory, you also don't know if your call to read or the memory you're copying to is actually in memory, it might block to page something in, which is also disk I/O and is comparable to the I/O for the actual file. So even if non-blocking would "work" on local files (how could it, meaningfully?), it would be a hint at best. > Any suggestion ? Would async I/O help in a case like this, considering > the possible overhead for handling signals when a transfer is > complete ? Yes, aio is probably the best alternative. It is quite expensive, though. Another alternative is to use multiple processes, but it also has considerable overhead. FreeBSD and typical Unix-like systems in general aren't perfect. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message