getcwd() and friends.

Guy Harris guy at auspex.auspex.com
Wed Apr 19 18:54:14 AEST 1989


>The issue is not blocking temporarily while waiting for disk or network
>I/O to take place.  The problem is that the open system call, rather than
>succeeding or reporting an error, can simply block forever.  The O_NDELAY
>flag prevents this under both System V and BSD.  If you run NFS (which is
>not part of either System V or BSD UNIX at this point), then the O_NDELAY
>flag won't help you.

There is some confusion here.  The "block forever" stuff applies to
special files and FIFOs, not to regular files; while you can open a
special file or FIFO that exists on a remote machine, the file in
question refers to a local object.

If you do an open on a special file that exists on an NFS file system,
O_NDELAY most definitely *will* get passed to the *local* driver for
that special file's device, and it will act on it just as if you'd
opened a special file on a local file system (in fact, the driver has no
idea that the file exists on a remote machine - which, for the case of a
diskless machine, is the way it should be; if I open "/dev/console" on
my diskless workstation, I want *my* console, not the server's
console!). 

The same applies for FIFOs that exist on NFS file systems.  (They act as
rendezvous points for local processes only.)

In either case, the local software, when seeing the O_NDELAY, will honor
it if the file was an NFS file, as long as it would have honored it were
it a local file.  That is definitely true for FIFOs, at least under
SunOS, and true of tty devices, at least.



More information about the Comp.unix.wizards mailing list