Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!spool.mu.edu!olivea!nntp-sc.barrnet.net!netapp.com!netapp.com!not-for-mail
From: guy@netapp.com (Guy Harris)
Newsgroups: comp.unix.bsd
Subject: Re: Why select() returns ``exceptional'' for files?
Date: 20 Jan 1995 18:52:07 -0800
Organization: Network Appliance Corporation
Lines: 78
Message-ID: <3fpssn$2gk@nova.netapp.com>
References: <3fois1$5d5@shore.shore.net>
NNTP-Posting-Host: 192.9.200.13
Robert Withrow <witr@rwwa.com> wrote:
>The following program returns an ``exceptional'' condition
>from select() for files on FreeBSD2.0 and Sunos (the two
>unixoid oses I have access to...). Why?
I suspect it's because
1) the original BSD "select()" implementation returns, on plain
files, a "yes" for all kinds of select, whether it's read,
write, or exceptional condition;
2) the SunOS on which you tried it wasn't SunOS 5.x, so that it
has an implementation based on the original BSD
implementation, and thus gives the same behavior.
SunOS 5.x's SVR4-derived implementation atop "poll()" *doesn't* return a
"yes" for exceptional conditions:
c1$ ./stest
Poll got numfds=1, readable=1, exception=0
Right now, I don't know that anybody's come up with an interesting
definition for an "exceptional condition" on a file descriptor referring
to a plain file.
A while ago, I noticed that the Win32 API lets you block waiting for a
"change notification" on a directory. "FindFirstChangeNotification()"
creates a "notification handle"; the call specifies what changes are
interesting, with the changes you can specify as interesting being:
creating, deleting, or renaming files in the directory or
subdirectories thereof;
creating, deleting, or renaming directories in the directory or
subdirectories thereof (no, I don't know why that's different
from creating, deleting, or renaming files, but they're
different types of changes in Win32);
changing "attributes" of files or directories in the directory
or subdirectories thereof ("attributes" are probably described
elsewhere in the Win32 documentation, or maybe not);
changes to the sizes of files (or directories?) in the directory
or subdirectories thereof;
changes to the time of last modification of files (or
directories?) in the directory or subdirectories thereof;
"security-descriptor changes" in the watched directory or
subtree.
"FindNextChangeNotification()" blocks until an interesting change is
reported on that handle.
This appears to be there for the benefit of the File Manager, so that it
doesn't have to periodically check the files it's showing. I guess the
ability to select different conditions is an optimization, so that if
it's not displaying file modification times, it doesn't have to wake up
if that's all that changed; dunno whether that was worthwhile or not.
When I saw that, I wondered whether something similar could, or should,
be done for UNIX. I.e., would it be worthwhile to have an "exceptional
condition" on a plain file or directory be signalled whenever the file
or directory changes (either a change to the contents, or to its
attributes)? (That wouldn't be exactly the same as the Win32 "change
notification" on a directory, as in Win32 it applies to all
subdirectories of the directory, and lets you select different kinds of
notifications.)
I've no idea whether it'd be of any use to programs other than, say,
"tail" when run with the "-f" flag, or file-manager programs for UNIX,
nor whether it'd be really painful to implement for NFS (as it'd have to
poll the server, periodically checking to see whether the file's
attributes have changed) or other distributed file systems.
(I.e., I've no idea whether it's a stupid idea or not. I don't consider
the fact that it was inspired by a Win32 idea to be sufficient to render
it stupid, though....)