DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9011>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9011 Worker-MPM error log: the listener thread didn't exit Summary: Worker-MPM error log: the listener thread didn't exit Product: Apache httpd-2.0 Version: 2.0.36 Platform: Sun OS/Version: Solaris Status: NEW Severity: Minor Priority: Other Component: worker AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] With Worker-MPM on Solaris (both 2.6 and 8) I get error messages "[crit] the listener thread didn't exit" every few minutes. The system was under heavy load (10-18 child processes) with (intentionally) non-keepalive requests. By adding traces I found that the dummy_signal_handler in worker.c does get called 10 times for the correct thread, but the function apr_proc_mutex_lock never returns. I think this behaviour does not deserve a LOG_CRIT which might unneccessarily alert the administrator as it can occur quite normally: According to the man page for pthread_mutex_lock: "If a signal is delivered to a thread waiting for a mutex, upon return from the signal handler the thread resumes wait- ing for the mutex as if it was not interrupted." And for other lock types which do not behave the same way proc_mutex.c simulates this behaviour by making a loop over EINTR. By the way, should proc_mutex.c set PTHREAD_MUTEX_RECURSIVE if such is defined on the system? The man page says the behaviour is undefined for default. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
