home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.21 / text0132.txt < prev    next >
Encoding:
Text File  |  1990-10-26  |  1.9 KB  |  39 lines
  1. Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  2.  
  3. In article <543@usenix.ORG> henry@zoo.toronto.edu (Henry Spencer) writes:
  4. > In article <541@usenix.ORG> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
  5. > >In the filesystem abstraction, you open a filename in one stage. You
  6. > >can't do anything between initiating the open and finding out whether or
  7. > >not it succeeds. This just doesn't match reality, and it places a huge
  8. > >restriction on programs that want to do something else while they
  9. > >communicate.
  10. > Programs that want to do two things at once should use explicit parallelism,
  11. > e.g. some sort of threads facility.  In every case I've seen, this yielded
  12. > vastly superior code, with clearer structure and better error handling.
  13.  
  14. I agree that programs that want to do two things at once should use
  15. threads. However, a program that sends out several connection requests
  16. is *not*, in fact, doing several things at once. open() forces it into
  17. an unrealistic local model; surely you agree that this is not a good
  18. semantic match for what actually goes on.
  19.  
  20. That example shows what goes wrong when locality disappears. As another
  21. example, NFS (as it is currently implemented) shows what goes wrong when
  22. reliability disappears. Have you ever run ``df'' on a Sun, only to have
  23. it hang and lock up your terminal? Your process is stuck in kernel mode,
  24. waiting for an NFS server that may be flooded with requests or may have
  25. crashed. Programs that use the filesystem for IPC assume that their
  26. files won't just disappear; this isn't true under NFS.
  27.  
  28. I am not saying that networked filesystems are automatically a bad
  29. thing. Quite the contrary: a distributed filesystem with caching and
  30. other forms of replication can easily be local and reliable, and I'll
  31. gladly see standard UNIX make provisions for it. But something that's
  32. not local, or not reliable, or not static, is also not necessarily
  33. appropriate for the filesystem.
  34.  
  35. ---Dan
  36.  
  37. Volume-Number: Volume 21, Number 132
  38.  
  39.