Mailing List Archive

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: bugs@httpd.apache.org
ReportedBy: erich.prchal@siemens.at


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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org