[Lldb-commits] [PATCH] D60468: Lock accesses to OptionValueFileSpecList objects

This revision was automatically updated to reflect the committed changes. Closed by commit rLLDB359028: Lock accesses to OptionValueFileSpecList objects (authored by friss, committed by ). Herald added a subscriber: teemperor. Herald added a project: LLDB. Changed prior to commit: https://revie

[Lldb-commits] [PATCH] D60468: Lock accesses to OptionValueFileSpecList objects

clayborg accepted this revision. clayborg added a comment. This revision is now accepted and ready to land. Fine to fix the current issue. We should think about building this into the base class eventually. We can always have multi-threaded access, so we will always need to protect modifying ope

[Lldb-commits] [PATCH] D60468: Lock accesses to OptionValueFileSpecList objects

friss added a comment. There were no objections to the patch, and it fixes a real crash seen in the field so I'm going to check it in. There seems to be consensus that properties should be per-debugger, so I'll work on this when I get some spare cycles. Note that making that change won't preve

[Lldb-commits] [PATCH] D60468: Lock accesses to OptionValueFileSpecList objects

labath added a comment. In D60468#1460212 , @friss wrote: > In D60468#1460065 , @labath wrote: > > > No opinion on the patch, but what is the reason for having settings that > > are shared between multiple Debugger

[Lldb-commits] [PATCH] D60468: Lock accesses to OptionValueFileSpecList objects

jingham added a comment. In D60468#1460212 , @friss wrote: > In D60468#1460065 , @labath wrote: > > > No opinion on the patch, but what is the reason for having settings that > > are shared between multiple Debugge

[Lldb-commits] [PATCH] D60468: Lock accesses to OptionValueFileSpecList objects

friss added a comment. In D60468#1460065 , @labath wrote: > No opinion on the patch, but what is the reason for having settings that are > shared between multiple Debugger instances? My expectation was that the > debugger objects are completely independe

[Lldb-commits] [PATCH] D60468: Lock accesses to OptionValueFileSpecList objects

jingham added a comment. In D60468#1460065 , @labath wrote: > No opinion on the patch, but what is the reason for having settings that are > shared between multiple Debugger instances? My expectation was that the > debugger objects are completely indepen

[Lldb-commits] [PATCH] D60468: Lock accesses to OptionValueFileSpecList objects

labath added a comment. No opinion on the patch, but what is the reason for having settings that are shared between multiple Debugger instances? My expectation was that the debugger objects are completely independent, and I would be surprised if the value of some setting changed from under me b

[Lldb-commits] [PATCH] D60468: Lock accesses to OptionValueFileSpecList objects

friss added a comment. In D60468#1460013 , @clayborg wrote: > Almost seems like we can build the mutex into the base class OptionValue as > we need general threaded protection for every setting. They any function that > gets or sets the value should be a

[Lldb-commits] [PATCH] D60468: Lock accesses to OptionValueFileSpecList objects

clayborg added a comment. Almost seems like we can build the mutex into the base class OptionValue as we need general threaded protection for every setting. They any function that gets or sets the value should be able to protect itself using the base mutex CHANGES SINCE LAST ACTION https://r

[Lldb-commits] [PATCH] D60468: Lock accesses to OptionValueFileSpecList objects

friss created this revision. friss added a reviewer: clayborg. Before a Debugger gets a Target, target settings are routed to a global set of settings. Even without this, some part of the LLDB which exist independently of the Debugger object (the Module cache, the Symbol vendors, ...) access direc