Greg A. Woods writes:

quoted text
>have any implementation of POSIX IPC, so portable software the must run
>on NetBSD must still use UNIX System V IPC.
...
quoted text
>Message queues could have been a little bit simpler too I suppose,

I can hardly believe that someone is actually recommending the use of
this blasted, totally deprecated API.  SysV IPC is a horrible
anachronism with lots of inconsistencies and bad behaviour (can't be
multiplexed with files, identifiers & resources hang around when
process exits abnormally, sometimes until the system is rebooted (you
can't always ipcrm), small, fixed limits compiled into kernel etc.)
Given that both System V R4 and higher and 4.4BSD and higher provide
much better, mmap-based shared memory mechanisms which are supported in
one way or the other by most if not all systems today (e.g. Free/NetBSD
and, iirc, Solaris can do both the SVR4 method of shared mmapping of
/dev/zero aswell as the anon/shared method of 4.4BSD) there is little
point in programming for the SVIPC API, except as a fallback for
systems on which it is the only method available (GNU/Linux).  A
uniform interface which encapsulates those three methods (SVR4, 44BSD,
SVIPC) towards the rest of the application is easily written in a
couple dozen lines of code so there's no reason to use the SVIPC crap
on systems where it is not necessary.

-- 
  Matthias Buelow;  mkb@{mukappabeta.de,informatik.uni-wuerzburg.de}