https://issues.apache.org/bugzilla/show_bug.cgi?id=50261
--- Comment #7 from Eric Garreau <[email protected]> 2010-11-15 04:50:50 EST --- We also had the same problem on a SunOS/sparc host, and we have replaced "AcceptMutex pthread" (which is 100% fine on Linux) by "AcceptMutex posixsem" Our investigations have shown that the current code makes the assumption that the 'apr_proc_mutex_lock(accept_mutex)' call /may/ exit when the process is notified of a cancellation. Unfortunately, pthread_mutex_lock (when "AcceptMutex pthread") is not a cancellation point, so the call will not exit with a status code different of APR_SUCCESS, ... and the process will actually continue to wait for the next time it will be lucky enough to capture the mutex, and then exit thanks to 'if(listener_may_exit)'. On SunOS, it seems that the old processes are forgotten by the scheduler, so they stay visible "forever", until a genuine 'apachectl stop' is called ('apr_proc_mutex_lock()' exits when the mutex is destroyed). We have used the 'posixsem' type as a quick workaround (a semaphore is a cancellation point), but not compared the performance drop yet. We have not tried the 'sysvsem' type because 'posixsem' seemed to work. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
