You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@apr.apache.org by Eric Covener <co...@gmail.com> on 2008/04/15 13:01:26 UTC

Re: fcntl based mutex on Solaris/EM64T

On Fri, Sep 14, 2007 at 2:50 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>> *snip* can't use two independent fcntl locks on Linux, Solaris, ??
> Did we ever discuss what should be done about this??

Report on users@httpd reminds me to try to resurrect this.  I don't
see the discussion here but I vaguely recalls someone mentioning it
would not be acceptable to change APR to choose a different default
mutex (proc_pthread?) when available.  This would still allow a
program to explicitly choose fcntl mutexes and get itself in trouble
just like the native calls.

-- 
Eric Covener
covener@gmail.com

Re: fcntl based mutex on Solaris/EM64T

Posted by Joe Orton <jo...@redhat.com>.

On Tue, Apr 15, 2008 at 07:01:26AM -0400, Eric Covener wrote:
> On Fri, Sep 14, 2007 at 2:50 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> >> *snip* can't use two independent fcntl locks on Linux, Solaris, ??
> > Did we ever discuss what should be done about this??
> 
> Report on users@httpd reminds me to try to resurrect this.  I don't
> see the discussion here but I vaguely recalls someone mentioning it
> would not be acceptable to change APR to choose a different default
> mutex (proc_pthread?) when available.  This would still allow a
> program to explicitly choose fcntl mutexes and get itself in trouble
> just like the native calls.

The default was changed to fcntl because of the potential for deadlocks 
in use of cross-process pthread mutexes:

  http://marc.info/?l=apr-dev&m=108720968023158&w=2

are those issues not seen any more? Since that decision was due to a 
potential OS bug (robust mutexes which aren't robust) has it been 
confirmed with Sun that this fcntl/EDEADLK is definitely not an OS bug?

Regards,

joe