request_list.c:rl_free_entry() bad pthread_kill()?
What is the intent of the pthread_kill() in rl_free_entry()? AFAICT, child_pid is not in fact a *child* pid, it's a thread id. And in fact, in order for pthread_kill() to work at all, this *must* be the case. So the reason for my question is that sending SIGKILL to any thread in the process does NOT terminate that thread, it terminates the entire process. The only way to force a [POSIX] thread to terminate is to use cancellation, which is complex and would require significant updates to all modules if the intent of this code is to abort any current processing "now"-ish. -frank
Frank Cusack <fcusack@fcusack.com> wrote:
What is the intent of the pthread_kill() in rl_free_entry()? AFAICT, child_pid is not in fact a *child* pid, it's a thread id. And in fact, in order for pthread_kill() to work at all, this *must* be the case.
Yes.
So the reason for my question is that sending SIGKILL to any thread in the process does NOT terminate that thread, it terminates the entire process.
OK.
The only way to force a [POSIX] thread to terminate is to use cancellation, which is complex and would require significant updates to all modules if the intent of this code is to abort any current processing "now"-ish.
The CVS head has a "stop now" flag, which causes src/main/modcall.c to stop processing the request. If the blocked module can be convinced to return, then the thread should be available for other requests. But some client libraries are notorious for blocking and never returning to the caller when things go wrong. There's little the server can do in that case. Alan DeKok.
On May 10, 2006 1:01:59 PM -0400 Alan DeKok <aland@nitros9.org> wrote:
The CVS head has a "stop now" flag, which causes src/main/modcall.c to stop processing the request. If the blocked module can be convinced to return, then the thread should be available for other requests.
here's an idea. set the stop now flag, unlink the entry but don't free it. have modcall.c free the entry if the stop now flag is set when the thread returns from processing. That way, rl_deinit() (which calls rl_free_entry()) can do its stuff. However I don't know what impact there will be on rl_deinit() continuing while a module is processing a request under a previous configuration. I guess that's up to individual modules to handle failures gracefully. (eg a module might be reconfigured to use a different passwd file, and the old one removed while it's processing a request) I'm assuming rl_deinit() is used for server reload. -frank
participants (2)
-
Alan DeKok -
Frank Cusack