Interpreters integrity after prefork

[Massimo Manghi <ma...@unipr.it>]

Hi

as some of you will certainly know there's a discussion thread 
developing between Alexandre Ferrieux and Gustav Neumann which will 
certainly impact mod_rivet 2.2 series and the future 2.3 series when 
using mod_prefork_mpm.

They're moving to a new handling of Unix fork calls removing the 
pthread_atfork call that proved to be an easy way to have a working 
notifier in child processes (that call was introduced upon Harald's 
suggestion if I remember correctly). We'll have a way to restore the 
notifier anyway, but using this feature of mod_rivet will require a more 
accurate documentation of the implications and caveats.

For what I understand the new fork handling could slip into the next 
8.6.x release and therefore Tcl installation all around could be 
upgraded breaking existing installation of mod_rivet to handle 
asynchronous I/O. It's important we prepare to roll out a new 2.2.4 
release able to transparently handling the 2 ways to prepare the fork as 
soon as a strategy is adopted (lazy notifier initialization for what I 
can understand)

  -- Massimo

---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org

Re: Interpreters integrity after prefork

[Massimo Manghi <ma...@unipr.it>]

welcome back Harald

I probably blundered my goal with my message to the Tcl core list. 
Gustav answered telling the whole story of what a fork is. I know what a 
fork is. I did not insist though, sometime the dialog between Alexandre 
and Gustav was dense and for a while looked like was about to take a 
stubborn attitude, so I didn't want to add a third voice. I'm still 
concerned that we might run into troubles, Gustav clearly doesn't like 
fork at all and he's been pushing a solution fork-agnostic. I hope the 
trade off they found will square away every problem. OTOH for example we 
were very wise when we recommended not to leave I/O channels open when a 
ServerInitScript terminates.

I don't know what the guys at FA think of it, but if they still use the 
feature of interpreter cloning across a fork call I recommend they stay 
tuned on the core list to understand what happens

  cheers

  -- Massimo

On 17-08-2015 13:24, Harald Oehlmann wrote:
> Massimo,
> thank you careing and answering on the tcl core list.
>
> The lazy handling was discussed before. TCL is using that on the MAC
> with a list of around 100 open bug tickets ;-)
>
> It meight happen, that the notifier may work after the fork, as the
> fileevent command will automatically check if there is a notifier
> thread. If not (which is the case after the fork) it is started.
>
> The discussions between Alexandre and Gustav are much to complicated
> to me, as it was two years ago already ;-)
>
> I recommend to stay a bit quiet and observe what happens.
>
> I am back from holidays by the way ;-)
>
> Regards to the team,
> Harald
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org

Re: Interpreters integrity after prefork

[Harald Oehlmann <ha...@elmicron.de>]

Massimo,
thank you careing and answering on the tcl core list.

The lazy handling was discussed before. TCL is using that on the MAC 
with a list of around 100 open bug tickets ;-)

It meight happen, that the notifier may work after the fork, as the 
fileevent command will automatically check if there is a notifier 
thread. If not (which is the case after the fork) it is started.

The discussions between Alexandre and Gustav are much to complicated to 
me, as it was two years ago already ;-)

I recommend to stay a bit quiet and observe what happens.

I am back from holidays by the way ;-)

Regards to the team,
Harald


Am 06.08.2015 um 18:10 schrieb Massimo Manghi:
> Hi
>
> as some of you will certainly know there's a discussion thread
> developing between Alexandre Ferrieux and Gustav Neumann which will
> certainly impact mod_rivet 2.2 series and the future 2.3 series when
> using mod_prefork_mpm.
>
> They're moving to a new handling of Unix fork calls removing the
> pthread_atfork call that proved to be an easy way to have a working
> notifier in child processes (that call was introduced upon Harald's
> suggestion if I remember correctly). We'll have a way to restore the
> notifier anyway, but using this feature of mod_rivet will require a more
> accurate documentation of the implications and caveats.
>
> For what I understand the new fork handling could slip into the next
> 8.6.x release and therefore Tcl installation all around could be
> upgraded breaking existing installation of mod_rivet to handle
> asynchronous I/O. It's important we prepare to roll out a new 2.2.4
> release able to transparently handling the 2 ways to prepare the fork as
> soon as a strategy is adopted (lazy notifier initialization for what I
> can understand)
>
>   -- Massimo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>


-- 
ELMICRON Dr. Harald Oehlmann GmbH
Koesener Str. 85
06618 Naumburg
Germany
Phone: +49 (0)3445 78112-0
Fax: +49 (0)3445 78112-19
www.Elmicron.de
German legal references:
Geschaeftsfuehrer: Dr. Harald Oehlmann, Jens Oehlmann
UST Nr. / VAT ID No.: DE206105272
HRB 212803 Stendal

---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org