[Lldb-commits] [lldb] [lldb-dap] Reimplement `runInTerminal` with signals (PR #142374)

[Hu Jialun via lldb-commits]

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