jeffreytan81 wrote: > You are right, TryAllThreads defaults to True. > > Not using TryAllThreads is actually dangerous in the general case. For > instance, you can have the thread you run take a lock, then call some code > that tries another lock that is held by a thread we aren't running. That > times out so we cancel the execution evaluation but since we don't in general > know about all the locking strategies available on any given platform, we > don't know to unlock the first lock, and that will cause the program to > deadlock later on if anybody tries to get the first lock again. > > If you do the same thing with TryAllThreads set to true, then when the > expression deadlocks on the running thread, we give a chance for the thread > holding the second lock to release it, and the evaluation goes on to succeed, > releasing the first lock on the way out. > > Also, a very common workflow in debugging is to stop somewhere at a > breakpoint, run a couple of expressions and continue, and you don't really > care about the state of other threads. So true is the right default value. > > There is an overload of CreateValueFromExpression that takes an > EvaluteExpressionOptions, and if you are calling code internally you should > be using that one because you really should think about how you want the > expression to run.
Yeah, I see your point. VS debugger takes the other design decision to not run all threads, so it is notorious for expression evaluation causing IDE to deadlock or hang by accident. Eventually, they designed a UI to not automatically evaluate expressions in watch window but has a "dangerous" button next to each expression saying click at your own risk. https://github.com/llvm/llvm-project/pull/108414 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
