You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Trawick <tr...@attglobal.net> on 2002/04/04 22:39:41 UTC
Re: cvs commit: apr/locks/unix crossproc.c locks.c proc_mutex.c
jim@apache.org writes:
> jim 02/04/04 10:33:57
>
> Modified: . CHANGES configure.in
> include apr.h.in apr_global_mutex.h apr_lock.h
> apr_proc_mutex.h
> include/arch/unix locks.h proc_mutex.h
> locks/unix crossproc.c locks.c proc_mutex.c
> Log:
> Support for Posix semaphores for locking has been added. This uses
> named semaphores (sem_open). Because there are a few different
> implementations around, this uses the lowest common denominator in
> creating the semaphore name. As far as its location in DEFAULT
> priority, it's placed between pthread and sysvsem. Tested on
> Darwin (in which it's the new default) and Solaris.
"sem_open("/ApR.whatever", O_CREAT, 0644,1)" returns ENOSYS on Linux
(2.2.12 kernel). I'll try to add an autoconf check for that.
Beyond the issue mentioned above, why is a new lock mechanism
suddenly so high in the priority list? Aren't we throwing away a lot
of past experience (1.3 and 2.0)?
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: cvs commit: apr/locks/unix crossproc.c locks.c proc_mutex.c
Posted by Jeff Trawick <tr...@attglobal.net>.
Aaron Bannert <aa...@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...
Re: cvs commit: apr/locks/unix crossproc.c locks.c proc_mutex.c
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Aaron Bannert" <aa...@clove.org> wrote:
> 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).
>
> So is sem_open() broken on linux 2.2.12 or is it just being used incorrectly?
Isn't it somehow related to glibc rather than to the kernel?
Pier
Re: cvs commit: apr/locks/unix crossproc.c locks.c proc_mutex.c
Posted by Aaron Bannert <aa...@clove.org>.
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).
So is sem_open() broken on linux 2.2.12 or is it just being used incorrectly?
-aaron
Re: cvs commit: apr/locks/unix crossproc.c locks.c proc_mutex.c
Posted by Jeff Trawick <tr...@attglobal.net>.
Aaron Bannert <aa...@clove.org> writes:
> On Thu, Apr 04, 2002 at 03:39:41PM -0500, Jeff Trawick wrote:
> > "sem_open("/ApR.whatever", O_CREAT, 0644,1)" returns ENOSYS on Linux
> > (2.2.12 kernel). I'll try to add an autoconf check for that.
> >
> > Beyond the issue mentioned above, why is a new lock mechanism
> > suddenly so high in the priority list? Aren't we throwing away a lot
> > of past experience (1.3 and 2.0)?
>
> Posix semaphores appear to be the only non-filesystem-based way to
> get cross-process mutexes on Darwin. We're looking for a performance
> boost above fcntl/flock.
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.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: cvs commit: apr/locks/unix crossproc.c locks.c proc_mutex.c
Posted by Aaron Bannert <aa...@clove.org>.
On Thu, Apr 04, 2002 at 03:39:41PM -0500, Jeff Trawick wrote:
> "sem_open("/ApR.whatever", O_CREAT, 0644,1)" returns ENOSYS on Linux
> (2.2.12 kernel). I'll try to add an autoconf check for that.
>
> Beyond the issue mentioned above, why is a new lock mechanism
> suddenly so high in the priority list? Aren't we throwing away a lot
> of past experience (1.3 and 2.0)?
Posix semaphores appear to be the only non-filesystem-based way to
get cross-process mutexes on Darwin. We're looking for a performance
boost above fcntl/flock.
-aaron