Subject: Re: fsync performance hit on 1.6.1
To: Matthias Buelow <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 07/08/2003 21:59:14
[ 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
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; <email@example.com>; <firstname.lastname@example.org>
Planix, Inc. <email@example.com>; VE3TCP; Secrets of the Weird <firstname.lastname@example.org>