On Thursday 04 May 2006 19:16, Chris Darroch wrote:
> +#ifdef HAVE_PTHREAD_KILL
> + unblock_signal(WORKER_SIGNAL);
> + apr_signal(WORKER_SIGNAL, dummy_signal_handler);
> +#endif
> +
OK, unblock a signal. This happens after child_init, but presumably
won't interfere with existing modules 'cos a module that attaches a
handler for that in a child_init wouldn't have worked before, either.
Question: what other side-effects might this have? Anyone recollect
why signals are commonly blocked in the child processes?
> while (!workers_may_exit) {
> if (!is_idle) {
> rv = ap_queue_info_set_idle(worker_queue_info, last_ptrans);
> @@ -1077,6 +1095,13 @@
>
> for (i = 0; i < ap_threads_per_child; i++) {
> if (threads[i]) { /* if we ever created this thread */
> +#ifdef HAVE_PTHREAD_KILL
> + apr_os_thread_t *worker_os_thread;
> +
> + apr_os_thread_get(&worker_os_thread, threads[i]);
> + pthread_kill(*worker_os_thread, WORKER_SIGNAL);
> +#endif
> +
Works for me on Linux.
Now, what about a platform that HAS_PTHREAD_KILL, but which uses some
other form of threading in its APR (isn't that at least an option on some
FreeBSD versions?) Wouldn't this break horribly when it pthread_kills a
non-pthread? Couldn't it even happen on Linux, in principle at least?
--
Nick Kew
