[ On Wednesday, July 9, 2003 at 00:32:57 (+0200), Matthias Buelow wrote: ]
> Subject: Re: fsync performance hit on 1.6.1
>
> I can hardly believe that someone is actually recommending the use of
> this blasted, totally deprecated API.  SysV IPC is a horrible
> anachronism

SysV IPC is still a standard API and is far more portable than anything
else like it.  There's nothing wrong with it being "old".

> with lots of inconsistencies and bad behaviour (can't be
> multiplexed with files,

What do _you_ mean by "multiplexed"?  And are you talking explicitly
about message queues in particular?

> identifiers & resources hang around when
> process exits abnormally,

that's often thought of as a feature....

> sometimes until the system is rebooted (you
> can't always ipcrm),

Implementation bugs are not API deficiencies or design flaws.

> small, fixed limits compiled into kernel etc.)

Everything has limits -- at least with SysV IPC you know what they are
up front and you can tune your system to match your requirements.

> 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.

no need to write it from scratch -- Richard Stevens already wrote one.

Indeed POSIX IPC mechanisms are far more desirable, but also equally
non-portable until a majority of modern OS releases catch up to
P1003.1-2001 and are deployed in a significant number of installations.

-- 
								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>