Hi --
>> Does anyone have any advice? Does this seem like a problem
>> to be addressed? I tried to think through how one could signal
>> the poll()ing worker threads with pthread_kill(), but it seems
>> to me that not only would you have to have a signal handler
>> in the worker threads (not hard), you'd somehow have to break
>> out of whatever APR wrappers are abstracting the poll() once
>> the handler set its flag or whatever and returned -- the APR
>> functions can't just loop on EINTR anymore. (Is it
>> socket_bucket_read() in the socket bucket code and then
>> apr_socket_recv()? I can't quite tell yet.) Anyway, it seemed
>> complex and likely to break the abstraction across OSes.
>>
>> Still, I imagine I'm not the only one who would really like
>> those worker threads to cleanly exit so everything else does ...
>> after all, they're not doing anything critical, just waiting
>> for the Keep-Alive timeout to expire, after which they notice
>> their socket is borked and exit.
Paul Querna wrote:
> To clarify, are you sure its not using EPoll instead of Poll?
The culprit is the poll() inside apr_wait_for_io_or_timeout(),
which is indeed being called from within apr_socket_recv(). The
stack is, basically:
apr_wait_for_io_or_timeout()
apr_socket_recv()
socket_bucket_read()
apr_bucket_read()
ap_rgetline_core()
ap_rgetline()
read_request_line()
ap_read_request()
ap_process_http_connection()
Here's the tail of my strace, after I hacked on waitio.c to
spit out a write() just before and after polling:
11:47:21.757774 write(15, "about to poll with timeout 15000\n", 33) = 33
11:47:21.757877 close(15) = 0
11:47:21.757943 munmap(0xb7fff000, 4096) = 0
11:47:21.758016 poll([{fd=14, events=POLLIN, revents=POLLNVAL}], 1,
15000) = 1
11:47:33.261025 +++ killed by SIGKILL +++
I'd really love to hear opinions on this. Would anyone like
a patch to make ap_reclaim_child_processes() to wait first for the
maximum configured Keep-Alive period?
If that's too hacky, then what's the consensus -- ignore the
issue, or try to invent a way for the worker (and event?) MPMs
to signal their worker threads? It would seem to me that,
other than major surgery on APR, the ideal would be for the
signal handler to perform this snippet from the tail of worker_thread():
ap_update_child_status_from_indexes(process_slot, thread_slot,
(dying) ? SERVER_DEAD : SERVER_GRACEFUL, (request_rec *) NULL);
apr_thread_exit(thd, APR_SUCCESS);
or at a bare minimum, the apr_thread_exit(). But I'm not sure
offhand if having signal handlers perform thread exits is possible;
I feel like it's verboten....
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
