Avoid non--async-signal-safe functions in child after fork

Posix requires that a process forked from a multi-threaded process only calls
async-signal-safe functions between fork and exec.  This has been observed to
cause trouble at least in an ASan build, where a forked sub-process (that wants
to proceed to exec java from getJavaProps,
jvmfwk/plugins/sunmajor/pluginlib/util.cxx) hangs in
__sanitizer::BlockingMutex::Lock from within ASan's operator new replacement,
from within the SAL_INFO in SvpSalInstance::CloseWakeupPipe, from within the
atfork_child handler established with pthread_atfork.  The rest of the calls in
SvpSalInstance::Create-/CloseWakupPipe appear to be async-signal-safe.

This pthread_atfork handler got introduced with
dbced8e8584b631524dacf607f752ebb734901db "Don't share the wakeup pipe with child
processes".  It is irrelevant when the child process will proceed to call exec.
And if the child process does not proceed to call exec (which is the intented
use case why it got added), the above-mentioned Posix requirement makes it look
unlikely that the child will operate properly (i.e., not call any async-signal-
safe functions), unless the parent process was single-threaded.

Change-Id: I9ecaf98597b396e0db83fe98fb11a7df7686e1d6

1 files changed, 2 insertions, 2 deletions

diff --git a/vcl/inc/headless/svpinst.hxx b/vcl/inc/headless/svpinst.hxx
index 76250b1dbaf7..f39fefd0f25b 100644
--- a/vcl/inc/headless/svpinst.hxx
+++ b/vcl/inc/headless/svpinst.hxx
@@ -92,8 +92,8 @@ public:
     SvpSalInstance( SalYieldMutex *pMutex );
     virtual ~SvpSalInstance();
 
-    void                    CloseWakeupPipe();
-    void                    CreateWakeupPipe();
+    void                    CloseWakeupPipe(bool log);
+    void                    CreateWakeupPipe(bool log);
 
     void                    PostEvent(const SalFrame* pFrame, ImplSVEvent* pData, sal_uInt16 nEvent);