JDevlieghere wrote: > My logic behind the `lldb_dap::protocol` types was to keep them as POD data > and to not have much (if any) logic in them so that if we need to move the > data between threads or queues we can be relatively confident that we're not > dealing data races. In swift terms (I'm more familiar with swift than c++), > the `lldb_dap::protocol` types would be `struct`'s that are all `Sendable`.
Totally, and I think that's a great design, and not something that would change in my suggestion, right? > I do like the more simplified `operator()` idea to help deal with the > cancelled / interrupted, my existing solution was done to support the > LegacyRequestHandlers since they're sending the responses as raw > `json::Value`'s still, but with the more unified approach we could handle the > cancellation in the `operator()` body. If we want to support cancellation before moving all the request over to the protocol class, can we *temporarily* store both the JSON and the Protocol in the class we instantiate per request (whether that's the RequestHandler itself, or a class wrapping it) and use whichever one we need for that given request? https://github.com/llvm/llvm-project/pull/130169 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
