On 5/7/06, Nick Kew [EMAIL PROTECTED] wrote:
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
On Mon, May 08, 2006 at 06:19:59AM -0400, Jeff Trawick wrote:
Question: what other side-effects might this have?
unpredictable if somebody/something sends AP_SIG_GRACEFUL to the child
process; it will land on random worker thread
(it might be nice for debugging if you could make processes
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
On 5/7/06, Nick Kew [EMAIL PROTECTED] wrote:
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
On Sunday 07 May 2006 23:07, Garrett Rooney wrote:
On 5/7/06, Nick Kew [EMAIL PROTECTED] wrote:
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
On 5/7/06, Nick Kew [EMAIL PROTECTED] wrote:
On Sunday 07 May 2006 23:07, Garrett Rooney wrote:
On 5/7/06, Nick Kew [EMAIL PROTECTED] wrote:
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
Hi --
An older but essentially identical version of this patch is
in Bugzilla PR #38737.
Using the worker MPM (but not the event MPM), if Keep-Alives
are enabled and the timeout is reasonably long (e.g., 15 seconds),
then worker threads wait in poll() after handling a request
for any
