On Fri, Feb 22, 2019 at 3:08 AM Yann Ylavic wrote:
> On Fri, Feb 22, 2019 at 9:33 AM Branko Čibej 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 t
On Fri, Feb 22, 2019 at 9:33 AM Branko Čibej 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
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 b
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
> ==
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
==
