[REVIEW 3-5-5 (2/3)][PUSHED 3-5] fdo#50603: Close fds across a restart of soffice on Mac OS X
Stephan Bergmann
sbergman at redhat.com
Tue Jun 19 23:41:58 PDT 2012
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
More information about the LibreOffice
mailing list