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? -aaron
