Aaron Bannert <aaron@clove.org> writes:
> On Thu, Apr 04, 2002 at 04:04:46PM -0500, Jeff Trawick wrote:
> > You should hard-code posix semaphores for Darwin in apr_hints.m4. We
> > should not be playing around with the lock choice and affecting
> > multiple systems when we get specific platform knowledge we want to
> > exploit. apr_hints.m4 is for that specific platform knowledge.
>
> I don't consider this to be platform specific knowledge. Posix semaphores
> can be used on other platforms as well (Jim said he tested it on
> Solaris).
There is a big difference between "can be used" and "should be used."
flock() "can be used" on a bunch of systems but nobody went to the
trouble to add the right AC_CHECK_LIB() function to pick up BSD
compatibility stuff because nobody wants to use it on those systems
because the performance is not up to par with the other choices.
What you are saying is they "should be used" on Darwin. Sorry, but I
cannot agree that that is anything but platform specific knowledge
:)
When an OS/390 kernel guru says SysV sems "should be used" on OS/390,
that is platform-specific knowledge and is unrelated to the fact that
SysV sems "can be used" on AIX (where pthread mutexes "should be
used" since their use results in better scalability of programs like
Apache).
> So is sem_open() broken on linux 2.2.12 or is it just being used incorrectly?
I looked at the usage (reviewing Stevens UNP volume 2) and the code looks
reasonable. In fact, I don't see how anybody could screw it up.
There is no "sem_open" in the 2.2.12 kernel sources. I googled and
found some weak indications that sem_open() doesn't work with this
level of glibc. I was surprised that I didn't get a crystal clear
indication (I did find a note from Ulrich Drepper in 1996 explaining
how they work and why he thought kernel support was needed; but lots
of things can happen since 1996 so that isn't a strong indication).
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...