Re: [REVIEW 3-5-5 (2/3)][PUSHED 3-5] fdo#50603: Close fds across a restart of soffice on Mac OS X

On 06/19/2012 04:20 PM, Michael Meeks wrote:
> On Tue, 2012-06-19 at 15:43 +0200, Stephan Bergmann wrote:
> > On 06/19/2012 02:52 PM, Michael Meeks wrote:
> > >         It -looks- like you do this on every startup, when in fact we really
> > > only want to do it -before- we run 'exec' in this rather rare re-start
> > > condition :-)
> >
> > For the given scenario, we really only need to do it *after* exec under
> > the restart condition on Mac OS X (not *before,* due to additional
> > threads still running then that must not be irritated by closing fds
> > they still operate on).  So doing it upon *every* start on Mac OS X
> > appeared to be the easiest fix.
>
>         Grief - but calling 'exec' is unlikely to leave the threads around of
> the previous process in some unharmed state - surely it will just
> terminate them all [ presumably that is what we want ;-].

No, it will surely not leave them around after exec, but if we close fds 
before exec, they will get in our way, leading to nasty signals or 
deadlocks (witness the rtl allocator machinery threads, where that 
machinery is using fd based memory regions).

>         If not, a quick:
>
>         if (!fork()) {
>                 // close all sockets
>                 exec (...);
>         }
>
>         Would presumably do what we want (?) :-)

No, the whole exercise (with exec from self on Mac OS X) is only there 
to prevent forking in the first place (which would confuse Mac OS X's 
view of what the LO process actually is).

> Hopefully we're not counting
> on some configuration writer thread to write the config :-)

That should hopefully not be the case.  (And esp. in the 
restart-after-crash scenario, the process is in an indeterminate state 
where all bets are off anyway.)  The configmgr writer thread writes a 
copy first and moves it to registrymodifications.xcu in what is 
hopefully an atomic operation.

Stephan