httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: [PATCH 5/6] hard restart on Linux #38737
Date Sun, 07 May 2006 20:46:27 GMT
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

Mime
View raw message