Aaron Bannert <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] Born in Roswell... married an alien...
