252
edits
Online Developer Meeting (2021-10-26): Difference between revisions
Online Developer Meeting (2021-10-26) (edit)
Revision as of 16:49, 26 October 2021
, 26 October 2021→Fallback topic: spawn with P_OVERLAY works differently on POSIX and Windows
| Line 29: | Line 29: | ||
* On Windows, <code>spawn</code> with <code>P_OVERLAY</code> also replaces the current process. But each process has a distinct id on Windows. I.e., the new process gets a different process id from the original one. Another process (like a terminal) waiting for the original process id will resume once the '''original''' process terminates. (The same happens with <code>exec</code>.) That leads to issues when trying to use the <code>octave.exe</code> wrapper on Windows. | * On Windows, <code>spawn</code> with <code>P_OVERLAY</code> also replaces the current process. But each process has a distinct id on Windows. I.e., the new process gets a different process id from the original one. Another process (like a terminal) waiting for the original process id will resume once the '''original''' process terminates. (The same happens with <code>exec</code>.) That leads to issues when trying to use the <code>octave.exe</code> wrapper on Windows. | ||
* Could we use <code>spawn</code> with <code>P_WAIT</code> instead? IIUC, that would require passing the return code from the spawned process. What else? | * Could we use <code>spawn</code> with <code>P_WAIT</code> instead? IIUC, that would require passing the return code from the spawned process. What else? | ||
* [jwe] We have too many different ways of starting and interacting with subprocesses (popen, popen2, system, spawn, procbuf, procstream, etc.). Is it possible to use just one C++ function to provide all the public functions we need to support? | |||
== Previous topics == | == Previous topics == | ||