You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Yann Ylavic <yl...@gmail.com> on 2019/02/21 18:11:35 UTC
Allow SIGUSR2 with apr_signal_thread()
Hi,
can we stop preventing APR users (e.g. httpd) from using SIGUSR2
because of the way a tool worked 16 years ago (and probably doesn't
anymore)? No sarcasm here, just a question...
IOW, may I:
Index: srclib/apr/threadproc/unix/signals.c
===================================================================
--- srclib/apr/threadproc/unix/signals.c (revision 1834551)
+++ srclib/apr/threadproc/unix/signals.c (working copy)
@@ -307,13 +307,7 @@ static void remove_sync_sigs(sigset_t *sig_mask)
/* the rest of the signals removed from the mask in this function
* absolutely must be removed; you cannot block synchronous signals
* (requirement of pthreads API)
- *
- * SIGUSR2 is being removed from the mask for the convenience of
- * Purify users (Solaris, HP-UX, SGI) since Purify uses SIGUSR2
*/
-#ifdef SIGUSR2
- sigdelset(sig_mask, SIGUSR2);
-#endif
}
APR_DECLARE(apr_status_t) apr_signal_thread(int(*signal_handler)(int signum))
?
Regards,
Yann.
Re: Allow SIGUSR2 with apr_signal_thread()
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Fri, Feb 22, 2019 at 3:08 AM Yann Ylavic <yl...@gmail.com> wrote:
> On Fri, Feb 22, 2019 at 9:33 AM Branko Čibej <br...@apache.org> wrote:
> > Even if that tool did work this way 16 years ago, this was the wrong way
> > to solve the "problem". It's not APR's job to support such tools (except
> > for pool debugging modes); it's the downstream application's.
>
> On Fri, Feb 22, 2019 at 9:52 AM Joe Orton <jo...@redhat.com> wrote:
> > +1 definitely, it's a bit bizarre that's done by default TBH.
>
> OK, so it's a candidate to 1.6 possibly? :p
>
> Frankly, I don't see how it could break someone, SIGUSR2 has never
> been received by any apr_signal_thread() handler so is in the list of
> ignored signals so far, and still will for existing users who don't
> care..
>
If you are developing code to actually work, testing major.minor for the
support of your desired feature makes more sense than checking m.m.s.
I'd suggest the enhancement to 1.7.0 is more appropriate than 1.6.6.
Re: Allow SIGUSR2 with apr_signal_thread()
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Feb 22, 2019 at 9:33 AM Branko Čibej <br...@apache.org> wrote:
> Even if that tool did work this way 16 years ago, this was the wrong way
> to solve the "problem". It's not APR's job to support such tools (except
> for pool debugging modes); it's the downstream application's.
On Fri, Feb 22, 2019 at 9:52 AM Joe Orton <jo...@redhat.com> wrote:
> +1 definitely, it's a bit bizarre that's done by default TBH.
OK, so it's a candidate to 1.6 possibly? :p
Frankly, I don't see how it could break someone, SIGUSR2 has never
been received by any apr_signal_thread() handler so is in the list of
ignored signals so far, and still will for existing users who don't
care..
Re: Allow SIGUSR2 with apr_signal_thread()
Posted by Joe Orton <jo...@redhat.com>.
On Thu, Feb 21, 2019 at 07:11:35PM +0100, Yann Ylavic wrote:
> Hi,
>
> can we stop preventing APR users (e.g. httpd) from using SIGUSR2
> because of the way a tool worked 16 years ago (and probably doesn't
> anymore)? No sarcasm here, just a question...
>
> IOW, may I:
+1 definitely, it's a bit bizarre that's done by default TBH.
Regards, Joe
> Index: srclib/apr/threadproc/unix/signals.c
> ===================================================================
> --- srclib/apr/threadproc/unix/signals.c (revision 1834551)
> +++ srclib/apr/threadproc/unix/signals.c (working copy)
> @@ -307,13 +307,7 @@ static void remove_sync_sigs(sigset_t *sig_mask)
> /* the rest of the signals removed from the mask in this function
> * absolutely must be removed; you cannot block synchronous signals
> * (requirement of pthreads API)
> - *
> - * SIGUSR2 is being removed from the mask for the convenience of
> - * Purify users (Solaris, HP-UX, SGI) since Purify uses SIGUSR2
> */
> -#ifdef SIGUSR2
> - sigdelset(sig_mask, SIGUSR2);
> -#endif
> }
>
> APR_DECLARE(apr_status_t) apr_signal_thread(int(*signal_handler)(int signum))
> ?
>
> Regards,
> Yann.
Re: Allow SIGUSR2 with apr_signal_thread()
Posted by Branko Čibej <br...@apache.org>.
On 21.02.2019 19:11, Yann Ylavic wrote:
> Hi,
>
> can we stop preventing APR users (e.g. httpd) from using SIGUSR2
> because of the way a tool worked 16 years ago (and probably doesn't
> anymore)? No sarcasm here, just a question...
>
> IOW, may I:
> Index: srclib/apr/threadproc/unix/signals.c
> ===================================================================
> --- srclib/apr/threadproc/unix/signals.c (revision 1834551)
> +++ srclib/apr/threadproc/unix/signals.c (working copy)
> @@ -307,13 +307,7 @@ static void remove_sync_sigs(sigset_t *sig_mask)
> /* the rest of the signals removed from the mask in this function
> * absolutely must be removed; you cannot block synchronous signals
> * (requirement of pthreads API)
> - *
> - * SIGUSR2 is being removed from the mask for the convenience of
> - * Purify users (Solaris, HP-UX, SGI) since Purify uses SIGUSR2
> */
> -#ifdef SIGUSR2
> - sigdelset(sig_mask, SIGUSR2);
> -#endif
> }
>
> APR_DECLARE(apr_status_t) apr_signal_thread(int(*signal_handler)(int signum))
> ?
Even if that tool did work this way 16 years ago, this was the wrong way
to solve the "problem". It's not APR's job to support such tools (except
for pool debugging modes); it's the downstream application's.
-- Brane