home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.21 / text0074.txt < prev    next >
Encoding:
Internet Message Format  |  1990-10-26  |  2.6 KB
  1. From:  preece@urbana.mcd.mot.com (Scott E. Preece)
  2.  
  3. | From:  sp@mysteron.osf.org (Simon Patience)
  4.  
  5. | The reason for semaphores not being in the file system is twofold. Some
  6. | realtime embedded systems do not have a file system but do want semaphores
  7. | So this allows them to have them without having to bring in the baggage a
  8. | file system would entail.
  9. ---
  10. I don't care whether they have something that looks like UNIX filesystem
  11. code or not, or whether they have disk drives or not, but I don't think
  12. it's unreasonable to require them to handle semaphore names as though
  13. they were in a filesystem namespace.  Otherwise you're going to end up
  14. with a collection of independent features, each minimally specified so
  15. that it can work without assuming anything else, and anyone with any
  16. sense is going to say "Yuck" and use a real operating system that
  17. provides reasonable integration and for a uniform notion of, among other
  18. things, naming.
  19. ---
  20. | ...         Secondly, as far as threads, which are supposed to
  21. | be light weight, are concerned it allows semaphores to be implmented in user
  22. | space rather than forcing them into the kernel for the file system.
  23. ---
  24. Eh?  I don't know what the group has proposed since the ballot, but it
  25. would seem that using a filesystem name only makes a difference when you
  26. first specify you're going to be looking at a particular semaphore,
  27. which shouldn't be a critical path event.  After that you use a file
  28. descriptor, which I think could be handled in user space about as well
  29. as anything else.  In either case you're going to have to go to the
  30. kernel when scheduling is required (when you block or when you release
  31. the semaphore).
  32. ---
  33. | A good reason for *not* having IPC handles in the file system is to allow
  34. | network IPC to use the same interfaces. If you have IPC handles in the
  35. | file system then two machines who have applications trying to communicate
  36. | would also have to have at least part of their file system name space to
  37. | be shared. This is non trivial to arrange for two machines so can you
  38. | imaging the problem of doing this for 100 (or 1000?) machines.
  39. ---
  40. You're going to have to synchronize *some* namespace anyway, why
  41. shouldn't it be a piece of the filesystem namespace?
  42.  
  43. A consistent approach to naming and name resolution for ALL global
  44. objects should be one of the basic requirements for any new POSIX (or
  45. UNIX!) functionality.  We should have *one* namespace so that we can
  46. write general tools that only need to know about one namespace.
  47. --
  48. scott preece
  49. motorola/mcd urbana design center    1101 e. university, urbana, il   61801
  50. uucp:    uunet!uiucuxc!udc!preece,     arpa:    preece@urbana.mcd.mot.com
  51.  
  52. Volume-Number: Volume 21, Number 75
  53.  
  54.