SuibianP wrote: Thanks for the response!
> Your method of receiving a signal may not work reliably in a multithreaded > process. It will not. Signal mask is thread local and the signal may be delivered to other threads instead of being deferred until `pselect`. `sigtimedwait` avoids the pitfall but is not supported on macOS and OpenBSD. Good to know there are existing parts to reuse. > I think you're doing that because you want to be sure the child exits, but I > don't think that's really necessary It turned out that that does not even work reliably. Seems that on BSD and macOS, `ptrace` completely reparents the process and the real parent cannot `waitpid` any more before tracing ends. > which may close the window once the process they launched exits Noted. This also means that on Windows (with no real `exec`) the launcher will have to stay around until the target exits. > Are you sure that's handled correctly here? Not yet. I have been trying things like retrying if not `eStopReasonExec` , but on macOS somehow the `SBProcess` had no thread on the second stop. > let me propose an alternative protocol using (named) pipes > we have a named pipe implementation for windows, and I believe we already use > it in some situations The current implementation is using named pipes, which I tried to extend to Windows in #121269. The named pipe semantics, however, was rather different between Windows and POSIX. https://github.com/llvm/llvm-project/pull/121269#discussion_r2079125631 --- I will see if the suggested socket abstraction has fewer lurking surprises across platforms. Failing that, I will try out SysV message queues. https://github.com/llvm/llvm-project/pull/142374 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
