apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: cvs commit: apr/dso/unix dso.c
Date Mon, 25 Mar 2002 22:53:48 GMT
On Mon, Mar 25, 2002 at 10:32:03PM +0000, Pier Fumagalli wrote:
> > Awesome! Does OS X have its own pthread implementation (not based on
> > FreeBSD's)?
> Apparently, since it works allright... This is all I can figure out though:
> [...]
> checking for pthread.h... yes
> checking whether pthread_getspecific takes two arguments... no
> checking whether pthread_attr_getdetachstate takes one argument... no
> checking for pthread_key_delete... yes
> checking for pthread_rwlock_init... no
> APR will use threads
> [...]

Can't really tell from that. Anyone else know what threading library
Darwin uses?

> > We use file-based
> > locks by default because they are the most portable, but if we had
> > reason to believe that another method was better then we could
> > change the default on a platform-by-platform basis in autoconf.
> > APR locks support a bunch of different interprocess lock types.
> Noticed that :) All I can tell you is that under Darwin the apr_lock
> implementation method is "SVR4-style fcntl()". Check this out:

Just an FYI: apr_lock is going away and should not be used. apr_proc_mutex
is a split-out of the interprocess parts of apr_lock.

> checking for semget... yes
> checking for semctl... yes
> checking for flock... yes
> checking for /dev/zero... (cached) yes
> checking for union semun in sys/sem.h... no
> checking for LOCK_EX in sys/file.h... yes
> checking for F_SETLK in fcntl.h... yes
> checking for SEM_UNDO in sys/sem.h... no
> checking for CODESET in langinfo.h... no
> checking for POLLIN in poll.h sys/poll.h... no
> checking for PTHREAD_PROCESS_SHARED in pthread.h... no
> checking for pthread_mutexattr_setpshared... no
> decision on apr_lock implementation method... SVR4-style fcntl()
> checking if interprocess lock affects threads... no
> On Darwin semget and semctl are there, but there is no SEM_UNDO, the
> pthread_mutexattr_setpshared (of course) is not there, but I'm wondering if
> there's another way to handle things without using files, which just is a
> kick in the **** :)

I dunno, don't have a darwin box. :)

> This is also because (apart from speed) most of the file paths in HTTPD are
> "hard coded" (check this as an example):
> # grep 'logs/.*lock' `find $HTTPD2_SRC/server/mpm -type f`
> ../netware/mpm_default.h:  #define DEFAULT_LOCKFILE "logs/accept.lock"
> ../perchild/mpm_default.h:#define DEFAULT_LOCKFILE "logs/accept.lock"
> ../prefork/mpm_default.h:#define DEFAULT_LOCKFILE "logs/accept.lock"
> ../worker/mpm_default.h:#define DEFAULT_LOCKFILE "logs/accept.lock"
> DOH! :) I don't have the "logs" directory in my HTTPD 2.0 install (took me
> ages to figure that out!)

Yeah, that's definately broken. Those should be defined in autoconf
to at least be relative to the $runtimedir.

> > (IME, pthread-based locks tend to be the fastest, but not many platforms
> > support that.)
> IME -> In My Experience ??? :) how about semaphores against file locks?

The question is if APR can support semaphores to be used as mutexes w/o
SEM_UNDO, and if it can will it be safe?

BTW, what does `grep SERIALIZE include/apr.h` produce on your darwin box?


View raw message