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
