On Tue, Jun 20, 2006 at 01:36:21AM +0900, Tsuyoshi SASAMOTO wrote:
> >[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 ser
>[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.
I guess this was caused by bug 39833 (now fixed in rev. 415267 & 415
Joe Orton wrote:
On Mon, Jun 14, 2004 at 08:22:41AM -0400, Jeff Trawick wrote:
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
On Mon, Jun 14, 2004 at 08:22:41AM -0400, Jeff Trawick wrote:
> 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
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 sy
Having taken the time to review some of the proc mutex code, it seems
both the process-shared pthread mutexes and POSIX semaphores differ from
the other locking types on Unix in two significant ways:
1) for both types, if a process segfaults whilst holding the lock, the
mutex is left in an undefin
