Signal-safe way to start a worker thread in each child process?
Hello all, We're developing an Apache module that requires a background thread to be running in each individual child process. We've been calling apr_thread_create() during the child_init hook, and at first that appeared to work. Then we started seeing intermittent hangs on worker shutdown. We found out that our background thread was intercepting signals that were meant for the main thread. Apparently the apr_setup_signal_thread() function is meant to prevent this from happening; its documentation says, Warning: This must be called before any threads are created. Unfortunately, mpm_worker calls apr_setup_signal_thread() _after_ it runs the child_init hooks (see the child_main() implementation in server/mpm/worker/worker.c), so we're not getting its protection. We could just call apr_setup_signal_thread() ourselves -- and doing that does fix the problem -- but that means that modules which are initialized after us will get the global protection too, which doesn't feel clean. So, a few questions: 1) Is creating a new thread during the child_init hook the correct way to ensure that each child process gets its own background thread? 2) If so, is it intended behavior that Apache calls apr_setup_signal_thread() after the child_init hook, instead of before it? In case it matters, this is httpd 2.4.10 on Linux. Thanks for your time! Jacob Champion LabVIEW RD National Instruments
Re: Signal-safe way to start a worker thread in each child process?
On Tue, 02 Jun 2015 14:15:18 -0500 Jacob Champion jacob.champ...@ni.com wrote: We could just call apr_setup_signal_thread() ourselves -- and doing that does fix the problem -- but that means that modules which are initialized after us will get the global protection too, which doesn't feel clean. So, a few questions: I don't know a clean answer: it's not a problem I've ever tackled. But if you don't find a better solution, you can improve a little on your existing one by running your child_init after other modules have done theirs with APR_HOOK_LAST. -- Nick Kew
Re: Signal-safe way to start a worker thread in each child process?
Hello, On Tue, Jun 2, 2015 at 9:15 PM, Jacob Champion jacob.champ...@ni.com wrote: We could just call apr_setup_signal_thread() ourselves -- and doing that does fix the problem -- but that means that modules which are initialized after us will get the global protection too, which doesn't feel clean. So, a few questions: 1) Is creating a new thread during the child_init hook the correct way to ensure that each child process gets its own background thread? I would say yes, currently, with the existing hooks (run by the children processes)... 2) If so, is it intended behavior that Apache calls apr_setup_signal_thread() after the child_init hook, instead of before it? I don't know if it's intended, but that's the current behaviour. Maybe a new hook is needed after apr_setup_signal_thread(), that would not be a huge change (backportable/acceptable IMHO). A workaround today is (as you did) to use the child_init hook registered with APR_HOOK_REALLY_LAST, so that it is called after all the others. Since the hook will also be called just before apr_setup_signal_thread(), and the latter can be called multiple times, it should work without causing any issue. Regards, Yann.
RE: TR of 2.4.13
Hi All, The SO_REUSEPORT patch is only lack one vote now. It would be really great if we can make it this time. Guys, please test it out and vote for us if you like it. It boosts your performance on bigger Xeon systems. Thanks, Yingqi -Original Message- From: Jeff Trawick [mailto:traw...@gmail.com] Sent: Tuesday, June 02, 2015 5:50 AM To: dev@httpd.apache.org Subject: Re: TR of 2.4.13 On 06/02/2015 07:32 AM, Jim Jagielski wrote: Although there are some cool things that I'd like to see in 2.4.13, I don't want to hold off any longer (plus, those cool things would be good incentive for a 2.4.14 sooner rather than later). I plan to TR 2.4.13 on Thurs, by Noon eastern. From a presentation last week to a Python user group: These slides refer to some small features introduced in httpd 2.4.13, which will be available very soon. ;)
Re: TR of 2.4.13
On Tue, Jun 2, 2015 at 11:58 PM, Jacob Perkins jacob.perk...@cpanel.net wrote: Any chance this one will make it into 2.4.13? We manually patched our distribution in April and haven’t had any issues. https://bz.apache.org/bugzilla/show_bug.cgi?id=57531 This has already been backported to 2.4.13 with http://svn.apache.org/r1668879 Regards, Yann.
Re: TR of 2.4.13
On Tue, Jun 2, 2015 at 6:32 AM, Jim Jagielski j...@jagunet.com wrote: Although there are some cool things that I'd like to see in 2.4.13, I don't want to hold off any longer (plus, those cool things would be good incentive for a 2.4.14 sooner rather than later). I plan to TR 2.4.13 on Thurs, by Noon eastern. +1, planning to match you with a TR of 2.2.30 on the same timetable. There is a nominally important last patch in 2.2 STATUS, if a third pair of eyes have the cycles to review it.
Re: TR of 2.4.13
Good afternoon! Any chance this one will make it into 2.4.13? We manually patched our distribution in April and haven’t had any issues. https://bz.apache.org/bugzilla/show_bug.cgi?id=57531 https://bz.apache.org/bugzilla/show_bug.cgi?id=57531 Thanks! On Jun 2, 2015, at 6:32 AM, Jim Jagielski j...@jagunet.com wrote: Although there are some cool things that I'd like to see in 2.4.13, I don't want to hold off any longer (plus, those cool things would be good incentive for a 2.4.14 sooner rather than later). I plan to TR 2.4.13 on Thurs, by Noon eastern. signature.asc Description: Message signed with OpenPGP using GPGMail
TR of 2.4.13
Although there are some cool things that I'd like to see in 2.4.13, I don't want to hold off any longer (plus, those cool things would be good incentive for a 2.4.14 sooner rather than later). I plan to TR 2.4.13 on Thurs, by Noon eastern.
Re: TR of 2.4.13
On 06/02/2015 07:32 AM, Jim Jagielski wrote: Although there are some cool things that I'd like to see in 2.4.13, I don't want to hold off any longer (plus, those cool things would be good incentive for a 2.4.14 sooner rather than later). I plan to TR 2.4.13 on Thurs, by Noon eastern. From a presentation last week to a Python user group: These slides refer to some small features introduced in httpd 2.4.13, which will be available very soon. ;)
Re: ALPN patch comments
Can you test the latest rev of the backport candidate? http://people.apache.org/~ylavic/httpd-2.4.x-alpn-v4.patch On Mon, Apr 27, 2015 at 11:06 AM Stefan Eissing stefan.eiss...@greenbytes.de wrote: Am 25.04.2015 um 11:47 schrieb Kaspar Brand httpd-dev.2...@velox.ch: On 22.04.2015 18:54, Jim Jagielski wrote: For me the time seems right to rip NPN out of trunk and only backport the ALPN code to 2.4. I'd be +1 for that. So, to get one step further, and since there were no explicit objections to removing NPN support so far (or arguments for keeping it, FWIW), I went ahead and took a stab at this with r1676004. Only tested in terms of compiles both w/ and w/o HAVE_TLS_ALPN, so it certainly needs more eyes before a backport proposal could be made. There's also a TODO: we should have a mod_ssl configuration parameter in ssl_engine_kernel.c which I'm unsure to what it refers. The „TODO“ is a leftover from before SSLAlpnPreference was introduced. It can be removed. I diff’ed the current mod_ssl against the 2.4 branch, removed everything but he ALPN changes and made a patch for my sandbox. This works on my OS X with mod_h2. My Ubuntu sandbox is still resisting as some test clients still link the system ssl which only speaks NPN (or link against a lib_event that links against the system openssl). It’s a mess. Stefan Kaspar green/bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
