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