*BSD News Article 49018


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!vtc.tacom.army.mil!ulowell.uml.edu!europa.chnt.gtegsc.com!howland.reston.ans.net!news.sprintlink.net!news.primenet.com!ip214.pom.primenet.com!lclee
From: lclee@primenet.com (Larry Lee)
Newsgroups: comp.unix.programmer,comp.unix.bsd.bsdi.misc
Subject: Re: open() regular file nonblocking
Date: Sat, 19 Aug 1995 15:02:13 PST
Organization: Primenet
Lines: 42
Message-ID: <lclee.217.004ED1A4@primenet.com>
References: <4146ju$fup@nnrp3.primenet.com>
NNTP-Posting-Host: ip214.pom.primenet.com
X-Newsreader: Trumpet for Windows [Version 1.0 Rev B final beta #4]
Xref: euryale.cc.adfa.oz.au comp.unix.programmer:27811 comp.unix.bsd.bsdi.misc:615

In article <4146ju$fup@nnrp3.primenet.com> jdw@primenet.com (Jeff Wheelhouse) writes:
>From: jdw@primenet.com (Jeff Wheelhouse)
>Subject: open() regular file nonblocking
>Date: 19 Aug 1995 08:15:58 GMT

>I have a very, very busy disk (sectors per second 500+ continuously).  I
>also have a program that runs on this disk and opens (for reading only) 
>and closes a lot of existing files (say, 20 per second).  Unfortunately,
>because of the drive activity, the open() call blocks for up to half
>a second on each file, turning my 20-per-second into 2-per-second.  Is
>there any way I can issue an open() and have it return _right_ _away_,
>regardless of anything, so I can process other things and get back to this
>file once its available?  The system is BSDI.  O_NONBLOCK is apparently 
>not the correct answer; it seems to only handle "special" blocking 
>conditions, not something as mundane as the drive having 30 other requests
>to service first.

>If there isn't any way to background open, is there any way I can issue 
>some other background (or nonblocking) operation say a second or so
>beforehand, so by the time I get to the open(), it will be in cache?

>Thanks,
>Jeff

The open call does many things, allocate a file descriptor, search the 
directory for the file name, check the inode for permissions and file type
all of which have to be completed before the open can be determined to
be successful or not.  If an open call were to have an early return (non 
blocking) how would any of this information be communicated back to the 
program?

Simply having the file opened by a second process might bring the directory
information into the buffer cache, but on a system as busy as you describe
there is no guarantee that it will stay in cache long enough to be useful to 
a second call to open.

If you do this often, you might fork/exec a second process communicate with it 
via a pipe and have it do the open.  I seem to recall there was a method 
described in one of Stevens' books which allowed you to transfer an fd from 
one process to another.

Larry