fdeazeve added a comment. I am slightly wary of making this a global set without any kind of thread safe mechanism, as I (naively, not really knowing how this class is used) would expect us to be able to instantiate multiple servers and have them be accessed concurrently. As such, it makes more sense to have each server own its set of strings.
Have we considered having UnixSignals be the one to extend the lifetime of strings? I couldn't figure out if there is any advantage to this vs the other suggestion. ================ Comment at: lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp:48 +// from the remote, these strings need persistent storage client-side. +static llvm::StringSet<> g_signal_string_storage; ---------------- Is there a strong motivation for making this a global static, instead of a private member of PlatformRemoteGDBServer? My assumption here is that we only ever have one PlatformRemoteGDBServer active at any given time, otherwise (if concurrent servers now or in the future) the global approach is not thread safe. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D159011/new/ https://reviews.llvm.org/D159011 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
