labath wrote: Sorry about the delay. I have very mixed feelings about this PR. I too found the existing method of synchronization extremely clunky, so I definitely wouldn't be sad to see it go. However, I also have some reservations about this implementation: - you say you're assuming a single thread, but is that actually true. IIUC the signal receiving code runs inside the main lldb-dap process, which creates threads left and right. Your method of receiving a signal may not work reliably in a multithreaded process. We already have the MainLoop class, which knows how to wait for a signal in the presence of multiple threads. Unfortunately, it doesn't actually preserve the information about the sender. That should be relatively easy to fix though -- just have the signal handler save off the siginfo_t and then pass it to the callback. I would like to be able to reuse/extend that instead of building a new signal catching primitive. - in the launcher process, I see that you're doing a fork -- and then exiting from the parent. This sounds like it could confuse some terminals, which may close the window once the process they launched exits. I think you're doing that because you want to be sure the child exits, but I don't think that's really necessary -- one can imagine synchronization protocols which don't require waiting in a third process. You just need to avoid SIGSTOPping the child process, which is another potential source of problems here. - if the debugger attaches to the child process before it executes raise(SIGSTOP), the debugger will see one more stop by the child process than it might expect. Are you sure that's handled correctly here?
At the end of the day, I'm not really sure that signals are the best solution to this problem, as they interact strongly with the debugging APIs. The existing implementation was very.. baroque, but I think the choice of unix sockets was actually quite reasonable. With that in mind, let me propose an alternative protocol using (named) pipes: - child gets the socket name, writes the pid to it, and waits for EOF, if EOF doesn't come, it exits - parent listens on the socket, reads the pid, attaches to the process and then closes it This doesn't require any signals, nor iostreams, and is mostly portable (we have a named pipe implementation for windows, and I believe we already use it in some situations). 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
