[ On Tuesday, July 8, 2003 at 20:18:19 (+0200), Matthias Buelow wrote: ]
> Subject: Re: fsync performance hit on 1.6.1
>
> David Laight writes:
> 
> >SYSV shared memory is horrid stuff!
> >Just mmap a file!
> 
> Indeed, it is just compatibility stuff.  I'm apalled that new software
> is still using that deprecated (and ill-conceived) API.

New software _should_ use POSIX IPC, but of course NetBSD doesn't yet
have any implementation of POSIX IPC, so portable software the must run
on NetBSD must still use UNIX System V IPC.

It's really not that badly concieved an API, given the fact that it has
to be very portable; and it is very "standard" too (it's been in P1003.1
since Issue 2 and has been in the BASE API set since Issue 5).  (The
lack of ftok() in POSIX has also been repaired since Issue 4, IIRC.)

The full implementation gives some very nice user-level controls that
can be an enormous boon to debugging and operational management.

While a variant/subset of mmap() has been defined for IEEE-P1003.1-2001,
it ends up being a hell of a lot more complex than the plain old SysV,
aka XSI, shared memory you're complaining about and it doesn't include
MAP_ANON either so portable applications still have to use SysV/XSI SHM
for the kinds of uses I'm guessing are applicable for the application
this thread has been discussing.

The only part of the whole SysV IPC API that's really rather inelegant
is the semaphores part (and of course that's due to the minor flaw that
requires two separate system calls to create and then initialize a
semaphore).  IIUC this problem is fixed with POSIX semaphores, but of
course NetBSD doesn't yet have any implementation of POSIX semaphores.

Message queues could have been a little bit simpler too I suppose,
though only at the loss of some useful flexibility, and it is
unfortunate that you can't use poll() on message queues (sysV or posix).

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>