home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.20 / text0001.txt < prev    next >
Encoding:
Internet Message Format  |  1990-08-02  |  2.8 KB
  1. From: peter@ficc.ferranti.com (Peter da Silva)
  2.  
  3. I find myself in violent agreement with most of the points raised here,
  4. but there are two areas I don't think have been adequately thought through,
  5. and I have one alternative suggestion.
  6.  
  7. (mmap):
  8. > SVID 3 (System V Release 4.0), OSF AES (OSF/1), Berkeley BSD 4.4, MACH
  9. > 2.5, ULTRIX, SunOS, HP/UX, etc, all include an (almost) identical
  10. > definition of mmap() based on the current Sun/Berkeley specification.
  11.  
  12. V.3.2 does not include this interface, and V.3.2 is going to be around,
  13. and in fact very common, for at least a couple of years to come. A standard
  14. that locks out V.3.2 is going to hurt portability.
  15.  
  16. I believe that implementing shared memory in terms of memory mapped files
  17. is a good thing, and that every effort should be made to encourage it...
  18. within reason. Preventing the implementation of POSIX shared memory on
  19. the largest installed base of UNIX systems in existence is not within
  20. reason.
  21.  
  22. If the interface is "mmap" with a set of constant parameters, this will
  23. serve to hurt portability.
  24.  
  25.     a) People with "real mmap" will end up using more than the
  26.        standard allows. This is a pretty simple prediction... look
  27.        at existing extended implementations.
  28.  
  29.     b) People with the "fake mmap" will end up blowing the extra
  30.        parameters, "safely". Then when run on a system with the real
  31.        thing their programs will fail.
  32.  
  33. In practice, it would be best for both interfaces to (for portable
  34. programs, anyway) have a #define that hides the extra parameters. Which
  35. is exactly what the draft does.
  36.  
  37. (IPC in general):
  38. I don't believe the interface requires a shared file system. "mkmq()"
  39. can broadcast a message to all machines to create the named file as a
  40. normal file and place in it a special token. This token can be read from
  41. the file descriptor returned by "open()", and used by the "mq*()" routines
  42. to indicate the real name of the message queue.
  43.  
  44. I think it fairly important to put as many of the names of objects in the
  45. UNIX file system name space as possible. See pp 256,257.
  46.  
  47. And one minor point (a wish-list entry):
  48.  
  49. (sender_t in IPC):
  50. > The only information about the sender which would be useful
  51. > would be an indication about how to reply to the sender.  In
  52. > this framework that would be a pathname;
  53.  
  54. Or a file descriptor, perhaps? I had some questions about the utility of
  55. this feild, too, since it can't be used for any portable purpose. I'd rather
  56. see some meaning defined for it, though, than have it kicked out. Since
  57. returning an fd here is probably not a portable usage, this is a bit of a
  58. wish-list item...
  59. -- 
  60. `-_-' Peter da Silva. +1 713 274 5180.  <peter@ficc.ferranti.com>
  61.  'U`  Have you hugged your wolf today?  <peter@sugar.hackercorp.com>
  62. @FIN  Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf.
  63.  
  64. Volume-Number: Volume 20, Number 2
  65.  
  66.