JDevlieghere wrote: > > @kusmour Can you please confirm whether or not there's a reason to run the > > launch or attach commands in asynchronous mode? It looks like the > > divergence was introduced when the feature was added > > (https://reviews.llvm.org/D154028) and I'm not sure it's necessary. My > > local testing (using the `gdb-remote 3000` example from the README) seems > > to work as expected in synchronous mode and even seems like it would > > desirable? > > I just synced with Greg on some context. I think the nature of attachCommands > will allow people do anything. What if they have a waitFor command that will > not get timed out by GDBRemote timeout? Then lldb-dap will never return > anything to the client. The `dap.WaitForProcessToStop(timeout_seconds);` will > guarantee we at least return error if things aren't working.
Right, that's exactly the problem, and it goes both ways. Similarly to the situation where there's no stop, we have the same problem if there's more than one stop. > In fact maybe we should consider making the normal launch/attach in async and > have the `dap.WaitForProcessToStop(timeout_seconds);` at the end to ensure > the process is in expected state before responding to the launch/attach req? That's what I wanted to do originally, but I think that makes things strictly more complicated because it requires lldb-dap to deal with all the stops. Imagine you have a launch command that stops and resumes the inferior more than once. If we do that asynchronously, we'll get multiple stop events. - If stop-on-entry is false, we have to issue the continue so the process is running when the request completes. How do you know after which stop event to issue the continue? Because the process events are delivered asynchronously, you don't know when you're done handling all the events belonging to the launch or attach. - If stop-on-entry is false, we have to make sure the process is in a stopped state when the request completes. How do you know after which running event to issue the continue? At this point I'm convinced that there's no sound way of supporting all these scenarios from lldb-dap. The benefit of using synchronous mode is that we can let lldb itself deal with most of the stops, at the cost of potentially not doing the right thing when you have launch commands. I hope I'm wrong or missing something, but I would really like to solve this better, but I'm out of ideas. https://github.com/llvm/llvm-project/pull/138219 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
