labath added a comment. I didn't actually try it but I am pretty sure this will deadlock with nested lldb command files (running `command source` from a file that is itself being sourced). Changing the mutex to a recursive_mutex would fix that, but I don't believe it would make this fully correct -- it would just make it harder to demonstrate that it's wrong. OTOH, that may be the best thing we can do in the current state of affairs.
The thing I don't understand now is why do we even need this stack in the first place. It seems like this could be handled by just running a new iohandler "main loop" instead of pushing something. Take the "expr" command for example. In the single-line mode it evaluates the expression synchronously, but in a multi-line expression, it returns immediately after pushing it's own IOHandler (which then gathers the expression and calls back into the command to run it). I don't see why we couldn't achieve the same thing by "running" the iohandler directly, instead of pushing it to some stack and waiting for it to be executed at the top level. The same thing could be said for the "script" command and various other things which "hijack" the main (lldb) iohandler. Greg, am I missing something? ================ Comment at: lldb/include/lldb/Core/Debugger.h:406 IOHandlerStack m_input_reader_stack; + std::mutex m_io_hanlder_synchronous_mutex; + ---------------- typo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72748/new/ https://reviews.llvm.org/D72748 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
