[Lldb-commits] [lldb] [lldb-dap] Refactor request handlers (NFC) (PR #128262)

[Pavel Labath via lldb-commits]

https://github.com/labath commented:

I am thinking about how would this new approach work if we started executing requests in parallel (I know we're not planning to do that now, but this sort of started out from that), and it seems to me that the this design (a "singleton" object with a non-const member) isn't the best design for that. I think this could be improved in at least two ways, but the choice  depends on which way we'd like to take this:
- option one is to make operator() `const`. This guarantees the implementation doesn't store any information about the currently processed request in the object itself. This prevents "leaking" of data from one request into another and as a consequence, makes the object safe to use concurrently
- option two is to create a new handler object for request. This takes the opposite approach and actually encourages to (transiently) store information about the current request in the handler object (but then makes it safe by making sure the information is compartmentalized)

I don't want to make a choice here, since it depends on where you (the people who are actually going to be working on this) want to take this, but I think it would good to make a choice here, even if it gets changed later. The first approach (make the method const) would be most similar to status quo (because a free function doesn't even have an object to store information to), so maybe that could be the default?

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