apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject RFC: posixsem/pthread mutexes considered harmful
Date Mon, 14 Jun 2004 10:41:11 GMT
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 undefined (i.e. probably locked) state [1]. For the
other lock types, the mutex is unlocked and safe to use.

2) destroying a mutex in one process leaves it in an undefined state in
the other processes which forked and inherited the apr_proc_mutex_t. 
For the other lock types behaviour varies but is well-defined.

This trade-off against better performance for these two types doesn't
seem acceptable: e.g. for httpd/worker, a module segfault in a single
thread can cause a complete denial of service if the listener thread in
that process has the accept mutex locked.

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.


[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. 

View raw message