home *** CD-ROM | disk | FTP | other *** search
/ Peanuts NeXT Software Archives / Peanuts-4.iso / developer / unix / SysVIPC-3.4.README < prev   
Encoding:
Text File  |  1996-02-25  |  3.3 KB  |  86 lines
  1. System V IPC Semaphore and Shared Memory emulation routines for NeXT.
  2. --------------------------------------------------------------------
  3.  
  4.     Copyright (C) 1993--1996  Tom R. Hageman. <tom@rna.nl>
  5.  
  6.  
  7. Introduction.
  8. ------------
  9.  
  10. This package is an emulation of shared memory and semaphore routines as
  11. known from UNIX System V.  It is based on the mmap() system call which
  12. provides shared memory on Mach OS. (note that mmap is as yet
  13. undocumented and presumably not supported by NeXT.)
  14.  
  15. License
  16. -------
  17.  
  18. Read SysVIPC-3.4.Announce.rtf (RTF format) and SysVIPC-3.4.License.rtf (RTF
  19. format) for details.  In short SysVIPC is shareware for non-commercial
  20. educational use (note, 'educational use' and not 'educational users') and
  21. is commercially licensed otherwise.
  22.  
  23.  
  24. Installation.
  25. ------------
  26.  
  27. If you have the source distribution, run `make install'.
  28. If you have the Installer package (SysVIPC.pkg), just install.
  29.  
  30. This copies the library "libIPC.a" to "/usr/local/lib"
  31. and the "sys/*.h" header files to "/LocalDeveloper/Headers".
  32. These directories are in the search path of the compiler, so if you
  33. want to use these routines all you have to do is link with "-lIPC".
  34.  
  35. (For convenience/compatibility with other systems "/usr/local/include"
  36.  is created as a link to "/LocalDeveloper/Headers" if it does not yet exist.)
  37.  
  38.  
  39. Implementation notes and limitations.
  40. ------------------------------------
  41.  
  42. The implementation is as good as 100% complete (sometimes even more than
  43. complete). There are a few minor incompatibilities and some extra
  44. compatibilities beyond the API on the implementation level. These
  45. differences are (implementation level compatibilities are marked with '+',
  46. incompatibilities are marked with '–' and remarks are marked with 'o'):
  47.  
  48.  + Shmids and semids are system-wide unique -- as most System V
  49.    implementations.  This means that you can create, for instance, a
  50.    semaphore set with semget() in one process, scribble the semid
  51.    obtained by that down, and use it directly in another process to
  52.    access that same semaphore set.
  53.  
  54.  - You cannot give away a semaphore- or shared-memory id to another user
  55.    unless you are the super user.  A semid or shmid is owned by a single
  56.    user at a time, just like a file.  (on system V it can be owned by
  57.    the creator and another user.)
  58.  
  59. Semaphores:
  60.  
  61.  - all semop() and semctl() operations require READ + WRITE access to the
  62.    semid, even those that according to the documentation only need READ
  63.    access.
  64.  
  65. Shared memory:
  66.  
  67.  + a single shmid can be attached multiple times by the same program
  68.    (to different addresses) -- this is the behaviour of most System V
  69.    implementations, but it is usually not clearly documented.
  70.  
  71.  o all shmids require at least READ access in order to be useful --
  72.    this is also true of System V shmids, but again, is usually not
  73.    clearly pointed out.
  74.  
  75.  - shmat() and shmdt() cannot update the shmid_ds control structure
  76.    if the shmid is read-only.
  77.  
  78.  - the emulation is not aware of processes that do not explicitly detach
  79.    their shared memory segments before exiting.  In short, the `shm_nattch'
  80.    count may not reflect the actual number of segments attached.
  81.  
  82.  o the shmctl() commands SHM_LOCK and SHM_UNLOCK are currently not
  83.    implemented -- these are used in other implementations to lock /
  84.    unlock the shared memory segment in physical memory, i.e., to avoid
  85.    swapping (for performance?)
  86.