[Lldb-commits] [lldb] [lldb-dap] Refactoring lldb-dap to support running in a server mode, allowing multiple connections. (PR #114881)

[Pavel Labath via lldb-commits]

================
@@ -9,21 +9,28 @@
 #ifndef LLDB_TOOLS_LLDB_DAP_BREAKPOINTBASE_H
 #define LLDB_TOOLS_LLDB_DAP_BREAKPOINTBASE_H
 
-#include "llvm/Support/JSON.h"
 #include <string>
 
+#include "llvm/Support/JSON.h"
+
+#include "DAPForward.h"
+
 namespace lldb_dap {
 
 struct BreakpointBase {
+  // Associated DAP session.
+  DAP *dap;
----------------
labath wrote:

Although I don't consider myself an lldb-dap maintainer, I want to speak out, as strongly as I can, against the usage of shared/weak_ptr here. I have a couple of reasons for that:
1. it's an LLDB tradition that can't be found almost anywhere else in llvm
2. it encourages "vague ownership" semantics, where noone can be really sure whether some object still exists or not (so it handles the "not" case "just in case"). This in turn leads to a lot of dead/untested code. If what you say is true and the DAP object is the owner of this object, then I would say this is a reason to *not* use weak (or shared) pointers, as that the owned object should be able to assume that its owner is always around (and not worry about what to do with a possibly empty result of `weak_ptr::lock`). LLDB sort of has an excuse for using shared_ptrs (a python scripting API, which means code outside our influence can hold on to lldb objects), but I don't think anything like that applies to lldb-dap.
3. it's impossible to distinguish a "potentially empty" shared/weak pointer from one that is always set. This is kind of similar to the previous one, but without the temporal aspect. Even if you ignore the possibility of the object going away mid-flight, you still can't enforce that it is always there to start with. With raw pointers/reference, you can.
4. Makes it harder to maintain const correctness. It still possible (`shared_ptr<const T>` is a thing), but it seems people don't usually bother to do that. Const correctness is of particular importance for multithreaded code.
5. All of this copying, locking and atomic operations inherent in shared pointers make things slower.

https://github.com/llvm/llvm-project/pull/114881