Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: comp.unix.wizards
Subject: select() on disk files should stop lying
Message-ID: <7865@hoptoad.uucp>
Date: 6 Jul 89 01:51:00 GMT
Organization: Grasshopper Group in San Francisco
Lines: 36

I've been thinking of reasons why interactive response is so random
when running a network window system such as NeWS under a Unix kernel.
A slow window system can be tolerated, but one where response time
varies at random from subsecond to 10-second or longer is VERY hard to
get used to.  I have been working to eliminate many factors (running in
physical memory rather than virtual, eliminate other running processes,
etc) but one occurred to me that I can't fix.

NeWS has a central dispatch loop that does a select() on a mess of file
descriptors and handles whatever ones are ready to read or write.  This
works fine if those file descriptors are network sockets or pipes.  The
problem is if they are "normal" disk files; select() always claims that
they're ready to read or write.  Even on local disks, this is a lie,
but with remote files, it's a "damned lie".  A read() on such a file
will hang for an indefinite period, after select() says "sure, you can
read it".  NeWS reads from normal files when loading in images, fonts,
and PostScript code.  While doing so, response time to network sockets
is impacted, since NeWS will hang waiting for disk rather than handle a
network request that arrives first.

My first cut at a proposed fix is:  When a "normal" file is select()ed
for read, only return "ready" when a block has been read ahead into the
buffer cache.  If necessary, start a readahead on that file.  This
should be done regardless of whether the file is local or remote
(rewinding the tape drive causes MY scsi bus to hang for more than a
minute, how about yours!).  Select() for write should only succeed if a
write would accept a block for writebehind without sleeping.

Of course, by the time the process is dispatched, the readahead block or
the block available for writing could be gone; that's the breaks.  Also,
avoiding hangs requires that the application do its I/O in chunks of the
buffer size or less, but that's no problem.
-- 
John Gilmore      {sun,pacbell,uunet,pyramid}!hoptoad!gnu      gnu@toad.com
      "And if there's danger don't you try to overlook it,
       Because you knew the job was dangerous when you took it"