apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: RFC: posixsem/pthread mutexes considered harmful
Date Mon, 14 Jun 2004 12:22:41 GMT
Joe Orton wrote:

> So, I'm proposing that _POSIXSEM or _PROC_PTHREAD should never be made
> the default locking mechanism.  Nothing to stop those who understand the
> trade-off making an informed choice, of course.

generally +1, though I'm concerned that Solaris may not have a good default due 
to the sysdef+reboot requirements which are often required with the alternative 

> [1] supposedly on Solaris, this is solved for pthread mutexes by setting
> the "robust" attribute, but evidence in bugzilla from at least one
> tester was that mod_include segfaults using worker on Solaris could hang
> the server. 

Yes, this cannot be considered solved by any stretch of the imagination. 
Somehow the "robust" logic is prone to fail in production environments even 
though it always works beautifully when I'm trussing the child processes to see 
what happens.  I've seen this failure at multiple customer sites.

But on the other hand Solaris has a special system configuration concern:

With a default Solaris install, SysV sems often fail, particularly with 
unthreaded server, until tuning is made (not enough undo structures) and the 
system rebooted.

With a default Solaris install, the default limit of outstanding fcntl lock 
requests is 512 and requires a reboot to increase...  this limit seems to be 
system-wide across all locks.  Less likely to hit this limit than the SysV sem 
undo structure limit I suppose.

I guess the bright side is that we're less likely to hit these limits with a 
threaded web server, and a threaded web server is where we have the good chance 
of segfaulting while holding the accept mutex.

Any other info about sysvsem/fcntl concerns on Solaris?

I'm +0.5 for moving to a safer mutex mechanism on Solaris.


Meanwhile, we have the capability to pre-select the default lock method in 
apr_hints.m4 where we have system-specific knowledge about what ought to be 
used.  No reason to leave the choice up to the whims of people trying to make 
global decisions on mutex mechanisms based on various coolness factors when 
there is a clear winner for the platform.  For example, I'd be happy to see


in apr_hints.m4 for Linux.

View raw message