#include "wx/unix/execute.h"
#include "wx/unix/private.h"
+#ifdef wxHAS_GENERIC_PROCESS_CALLBACK
+#include "wx/private/fdiodispatcher.h"
+#endif
+
#include <pwd.h>
#include <sys/wait.h> // waitpid()
#if wxUSE_GUI
+#ifdef __DARWIN__
+ #include <sys/errno.h>
+#endif
// ----------------------------------------------------------------------------
// wxExecute support
// ----------------------------------------------------------------------------
-// Darwin doesn't use the same process end detection mechanisms so we don't
-// need wxExecute-related helpers for it
-#if !(defined(__DARWIN__) && defined(__WXMAC__))
+/*
+ NOTE: If this proves not to work well for wxMac then move back to the old
+ behavior. If, however, it proves to work just fine, nuke all of the code
+ for the old behavior. I strongly suggest backporting this to 2.8 as well.
+ However, beware that while you can nuke the old code here, you cannot
+ nuke the wxAddProcessCallbackForPid from the 2.8 branch (found in
+ utilsexc_cf since it's an exported symbol).
+ */
+// #define USE_OLD_DARWIN_END_PROCESS_DETECT (defined(__DARWIN__) && defined(__WXMAC__))
+#define USE_OLD_DARWIN_END_PROCESS_DETECT 0
+
+// wxMac/wxCocoa don't use the same process end detection mechanisms so we don't
+// need wxExecute-related helpers for them
+#if !USE_OLD_DARWIN_END_PROCESS_DETECT
bool wxGUIAppTraits::CreateEndProcessPipe(wxExecuteData& execData)
{
if ( !(flags & wxEXEC_NOEVENTS) )
{
-#if defined(__DARWIN__) && (defined(__WXMAC__) || defined(__WXCOCOA__))
+#if USE_OLD_DARWIN_END_PROCESS_DETECT
endProcData->tag = wxAddProcessCallbackForPid(endProcData, execData.pid);
#else
endProcData->tag = wxAddProcessCallback
);
execData.pipeEndProcDetect.Close();
-#endif // defined(__DARWIN__) && (defined(__WXMAC__) || defined(__WXCOCOA__))
+#endif // USE_OLD_DARWIN_END_PROCESS_DETECT
}
if ( flags & wxEXEC_SYNC )
int status = 0;
int result = waitpid(execData.pid, &status, 0);
+#ifdef __DARWIN__
+ /* DE: waitpid manpage states that waitpid can fail with EINTR
+ if the call is interrupted by a caught signal. I suppose
+ that means that this ought to be a while loop.
+
+ The odd thing is that it seems to fail EVERY time. It fails
+ with a quickly exiting process (e.g. echo), and fails with a
+ slowly exiting process (e.g. sleep 2) but clearly after
+ having waited for the child to exit. Maybe it's a bug in
+ my particular version.
+
+ It works, however, from the CFSocket callback without this
+ trick but in that case it's used only after CFSocket calls
+ the callback and with the WNOHANG flag which would seem to
+ preclude it from being interrupted or at least make it much
+ less likely since it would not then be waiting.
+
+ If Darwin's man page is to be believed then this is definitely
+ necessary. It's just weird that I've never seen it before
+ and apparently no one else has either or you'd think they'd
+ have reported it by now. Perhaps blocking the GUI while
+ waiting for a child process to exit is simply not that common.
+ */
+ if(result == -1 && errno == EINTR)
+ {
+ result = waitpid(execData.pid, &status, 0);
+ }
+
+#endif
if ( result == -1 )
{
}
else // !wxEXEC_NOEVENTS
{
- // endProcData->pid will be set to 0 from GTK_EndProcessDetector when the
- // process terminates
+ // endProcData->pid will be set to 0 from
+ // wxHandleProcessTermination when the process terminates
while ( endProcData->pid != 0 )
{
bool idle = true;
}
}
+#ifdef wxHAS_GENERIC_PROCESS_CALLBACK
+struct wxEndProcessFDIOHandler : public wxFDIOHandler
+{
+ wxEndProcessFDIOHandler(wxEndProcessData *data, int fd)
+ : m_data(data), m_fd(fd)
+ {}
+
+ virtual void OnReadWaiting()
+ { wxFAIL_MSG("this isn't supposed to happen"); }
+ virtual void OnWriteWaiting()
+ { wxFAIL_MSG("this isn't supposed to happen"); }
+
+ virtual void OnExceptionWaiting()
+ {
+ int pid = (m_data->pid > 0) ? m_data->pid : -(m_data->pid);
+ int status = 0;
+
+ // has the process really terminated?
+ int rc = waitpid(pid, &status, WNOHANG);
+ if ( rc == 0 )
+ {
+ // This can only happen if the child application closes our dummy
+ // pipe that is used to monitor its lifetime; in that case, our
+ // best bet is to pretend the process did terminate, because
+ // otherwise wxExecute() would hang indefinitely
+ // (OnExceptionWaiting() won't be called again, the descriptor
+ // is closed now).
+ wxLogDebug("Child process (PID %i) still alive, even though notification was received that it terminated.", pid);
+ }
+ else if ( rc == -1 )
+ {
+ // As above, if waitpid() fails, the best we can do is to log the
+ // error and pretend the child terminated:
+ wxLogSysError(_("Failed to check child process' status"));
+ }
+
+ // set exit code to -1 if something bad happened
+ m_data->exitcode = (rc > 0 && WIFEXITED(status))
+ ? WEXITSTATUS(status)
+ : -1;
+
+ wxLogTrace("exec",
+ "Child process (PID %i) terminated with exit code %i",
+ pid, m_data->exitcode);
+
+ // child exited, end waiting
+ wxFDIODispatcher::Get()->UnregisterFD(m_fd);
+ close(m_fd);
+
+ m_data->fdioHandler = NULL;
+ wxHandleProcessTermination(m_data);
+
+ delete this;
+ }
+
+ wxEndProcessData *m_data;
+ int m_fd;
+};
+
+int wxAddProcessCallback(wxEndProcessData *proc_data, int fd)
+{
+ proc_data->fdioHandler = new wxEndProcessFDIOHandler(proc_data, fd);
+ wxFDIODispatcher::Get()->RegisterFD
+ (
+ fd,
+ proc_data->fdioHandler,
+ wxFDIO_EXCEPTION
+ );
+ return fd; // unused, but return something unique for the tag
+}
+#endif // wxHAS_GENERIC_PROCESS_CALLBACK
+
#endif // wxUSE_GUI
#if wxUSE_BASE
projects / wxWidgets.git / blobdiff