Re: POSIX.1 semaphores vs message queues

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Nov 9,  8:29am, Paul Goyette wrote:
} On Mon, 9 Nov 2015, Joerg Sonnenberger wrote:
} > On Mon, Nov 09, 2015 at 08:05:43AM +0800, Paul Goyette wrote:
} >> Well, both EXEC_SCRIPT and COREDUMP are modularized, and they _are_
} >> optional.
} >
} > See part about modularity masturbation. Making things optional for the
} > sake of making them optional is just as wrong.
} >
} >> Both EXEC_SCRIPT and COREDUMP are also much smaller than the ksem code;
} >> these two optional/removeable modules together add up to just about
} >> the size of a SEMAPHORE module.  (On amd64 we have exec_script weighing
} >> in at 1285 bytes and coredump at 3895 bytes, while ksem tips the scales
} >> at 5186 bytes).  There are numerous other modules which are similar in
} >> size to the SEMAPHORE module.
} >
} > Add in the page alignment and the cost becomes even larger. There is
} > nothing to be gained.
} 
} The gain is flexibility, for those who may want it.  And possibly
} finding (and eventually fixing) latent bugs, either in the semaphore
} code itself or in the module system, which can be exposed by making

     This second point is silly.  The module system has been pretty
thoroughly debugged at this point.  The primary sore point now is
modules that allow themselves to be unloaded when they have hooks
into the system.

} the code optional and loadable.
} 
} We also gain consistency with existing practice, evidenced by the
} various examples I've cited.

     Some of those examples might be considered to be errors, i.e.
EXEC_ELF<abi>, as the system can't run without it.  Propogating
errors is not generaly a good thing.

}-- End of excerpt from Paul Goyette