apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens-Uwe Mager <...@anubis.han.de>
Subject Re: cvs commit: apr/dso/unix dso.c
Date Mon, 25 Mar 2002 23:04:07 GMT
On Mon, Mar 25, 2002 at 02:53:48PM -0800, Aaron Bannert wrote:
> 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?

Darwin is a BSD kernel on top of MACH. The current implementation maps
POSIX threads to MACH kernel threads in a one to one implementation. The
implementation is not without flaws either, as for example there are
problems with cancellation, signal handling (I believe) and process
shared mutexes.

> > > 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. :)

There is no real cross process locking that works without a system call
in the non-congested case in Darwin. I did resort to using the spin
locks from the historic MACH cthreads implementation which is still used
in a lot of code from the standard libraries (both cthreads and pthreads
map to the underlying MACH kernel threads one to one). Unfortunately
they do not ship their cthread.h file they use to build the system, but
I grabbed it from the Darwin CVS.

-- 
Jens-Uwe Mager	<pgp-mailto:62CFDB25> <jabber:jum@jabber.com>

Mime
View raw message