apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davi Arnaut <d...@haxent.com.br>
Subject Re: RFC: nptl runtime enforcement
Date Mon, 02 Jul 2007 13:15:12 GMT
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

> (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

View raw message