Joe Orton wrote: > On Sat, Jun 30, 2007 at 08:47:59PM -0300, Davi Arnaut wrote: >> Posting to the list before committing since this may be a little bit >> controversial. >> >> The patch adds a new argument to the --enable-threads option, which >> enables a nptl-only build of apr. This enables the build process to make >> better assumptions regarding the behavior (and speed) of a few lock >> primitives (ie: apr_posixsem_is_global, much faster on nptl for >> inter-process mutexes). >> >> The patch still needs some tweaking here and there, but any comments or >> feedback would be greatly appreciated. > > Tying this to the name of the particular threading implementation seems > ugly; if all you want to do is enable apr_posixsem_is_global then why > not just use a hint in apr_hints.m4 for Linuxes >= 2.6?
apr_posixsem_is_global was just an example, there are many incompatibilities between LinuxThreads and NPTL (process shared resources, fork()/wait() on the child, thread termination on execve(), etc. What I want is to let the developer enforce that the build of APR he is distributing is only guaranteed to work linked with NPTL -- given that on almost any 2.6 distro the user may switch the pthread implementation using LD_ASSUME_KERNEL. > (FWIW, there are more considerations than speed when choosing an > inter-process locking mechanism: > http://marc.info/?l=apr-dev&m=108720968023158&w=2) Sure. That's why Robust Mutexes exist, and IIRC recent 2.6 kernels have robust futex support. Also, shouldn't we let the developer make the choice if he wants a robust mutex? Maybe a apr_proc_mutex_create flag, APR_LOCK_ROBUST meaning to use the safest mutex available on the platform and APR_LOCK_FAST for the fastest. -- Davi Arnaut
