Re: [REVIEW][3-5] misc stuff

On 04/17/2012 03:15 PM, Michael Stahl wrote:
> have oosplash forward SIGTERM to soffice.bin:
>
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=946e7180be96178937e7be1b0bd7132902709a87

The above is not a good idea.  At least with POSIX, there is no reliable 
way for a parent process to forward to a child process a signal that the 
parent receives.  There is always a window of time after fork(2) where 
the forwarding will not yet happen, and there is always a window of time 
after wait(2) where the forwarding will potentially send the signal to 
an unrelated process.  (Yes, I know, the soffice script tries to do the 
same, see 
<http://compgroups.net/comp.unix.shell/sh-terminating-children-upon-sigterm/501864> 
"sh: Terminating children upon SIGTERM" for a fruitless discussion.)

The two processes need to communicate shutdown requests with a more 
sophisticated protocol than trying to send a SIGTERM received by the 
parent on to the child.

That said:

* g_pProcess should at least be volatile (it can't be sig_atomic_t).

* New code should use sigaction(2), not signal(2).

* The sigterm_handler returns normally, effectively ignoring the 
SIGTERM.  Not sure if that is by design (as, if all goes well, 
termination of the child will lead to termination of the parent, anyway) 
or by accident.  (Though if it were by design, it would not take into 
account that a SIGTERM sent before spawning the child does not lead to 
timely termination.)

> these increase reliability of JUnit based test infrastructure:
>
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=90f7a3ada68f309a9d3201183ef552e59f9558fb
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=228515e7783aecdb992258765554a530d6c831f3

Not yet sure what to make of these two.  This is tricky territory, and a 
number of potential deadlocks had deliberately been left in, on the 
ground that (a) programmatically forcing termination of non-terminating 
processes does not guarantee resource clean up (i.e., spawned 
sub-processes can remain, see above), and (b) forcing termination 
prevents debugging of the underlying deadlock.

It is a fallacy that a hung build can be killed automatically and the 
machine be guaranteed to be in a clean state afterwards.

However, I will look into these two commits when I have a little more time.

Stephan