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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
