You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stefan Eissing <st...@greenbytes.de> on 2018/01/17 15:52:04 UTC

signals for workers

Hej Yann,

could you briefly scan https://bz.apache.org/bugzilla/show_bug.cgi?id=62009 and let me
know if the proposed workaround sounds reasonable? It sounds correct that h2 workers
should mask these signals so that mpm threads can handle them properly.

Thanks,

Stefan

Re: signals for workers

Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Jan 17, 2018 at 6:19 PM, Yann Ylavic <yl...@gmail.com> wrote:
>
> we are less protected against child_init()
> threads that would steal "our" MPM signals though, their bug IMO.

Scratch that, child_init() threads can do this after or before
apr_setup_signal_thread(), the difference is that after it needs to be
explicit.

Re: signals for workers

Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Jan 17, 2018 at 6:14 PM, Eric Covener <co...@gmail.com> wrote:
>>> Maybe h2 could just call this on each new thread, but not the
>>> primordial one child_init runs directly on?
>>
>> Or the MPM block signal before child_init(), it is usefull to create
>> threads from there w/o boring with masks...
>
> I was being paranoid about breaking someone, but that doesn't really
> make sense since they'd have to be setting handlers explicitly.

Yes, it's also my feeling, we are less protected against child_init()
threads that would steal "our" MPM signals though, their bug IMO.

Re: signals for workers

Posted by Eric Covener <co...@gmail.com>.
>> Maybe h2 could just call this on each new thread, but not the
>> primordial one child_init runs directly on?
>
> Or the MPM block signal before child_init(), it is usefull to create
> threads from there w/o boring with masks...

I was being paranoid about breaking someone, but that doesn't really
make sense since they'd have to be setting handlers explicitly.

Re: signals for workers

Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Jan 17, 2018 at 5:17 PM, Eric Covener <co...@gmail.com> wrote:
> On Wed, Jan 17, 2018 at 10:52 AM, Stefan Eissing
> <st...@greenbytes.de> wrote:
>> Hej Yann,
>>
>> could you briefly scan https://bz.apache.org/bugzilla/show_bug.cgi?id=62009 and let me
>> know if the proposed workaround sounds reasonable? It sounds correct that h2 workers
>> should mask these signals so that mpm threads can handle them properly.
>
> I think they should be blocked too.
>
> The reason they are unblocked is likely b/c the h2 worker threads are
> created (child_init) right before apr_setup_signal_thread() is called
> by the MPMs.

Ah, I read this after my comment on the PR, too bad.
It makes very much sense to me.

>
> Maybe h2 could just call this on each new thread, but not the
> primordial one child_init runs directly on?

Or the MPM block signal before child_init(), it is usefull to create
threads from there w/o boring with masks...

Regards,
Yann.

Re: signals for workers

Posted by Eric Covener <co...@gmail.com>.
On Wed, Jan 17, 2018 at 10:52 AM, Stefan Eissing
<st...@greenbytes.de> wrote:
> Hej Yann,
>
> could you briefly scan https://bz.apache.org/bugzilla/show_bug.cgi?id=62009 and let me
> know if the proposed workaround sounds reasonable? It sounds correct that h2 workers
> should mask these signals so that mpm threads can handle them properly.

I think they should be blocked too.

The reason they are unblocked is likely b/c the h2 worker threads are
created (child_init) right before apr_setup_signal_thread() is called
by the MPMs.

Maybe h2 could just call this on each new thread, but not the
primordial one child_init runs directly on?

-- 
Eric Covener
covener@gmail.com