labath added a comment. In D72748#1829956 <https://reviews.llvm.org/D72748#1829956>, @JDevlieghere wrote:
> In D72748#1823945 <https://reviews.llvm.org/D72748#1823945>, @labath wrote: > > > 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. > > > Isn't the problem that you can't be sure your IO handler pushes another one > on top of the stack? I considered an alternative implementation, where the > synchronous IO handlers has its own stack and everything that's pushed while > it is executing ends up on that stack. It adds a lot of complexity and you > still need to synchronize with the "main loop" Well.. in the way I as imagining things, there would be no stacks (at least no explicit stacks), no pushing, and everything would execute in the "synchronous" mode. So e.g., when we start up the main "(lldb)" loop, we just take that iohandler, and run it until it says it's done. If the user types "script", then we start another "main loop" with the python iohandler, but the main loop can be completely oblivious to that -- as far as it is concerned, its iohandler is still executing `CommandObjectScript::DoExecute`. When the user exits the python prompt the control returns to the (lldb) iohandler just like it would after any other "simple" command. So, essentially, there's still some stacking involved, but it's not managed explicitly -- it just comes out from the way the code is organized. Similarly, the "breakpoint command add" could run an iohandler to collect the breakpoint commands, "process continue" could run a loop to forward the inferior stdio, etc. (The last bit is tricky because of ^C, and it means that we will still need to have some global notion of the "active" or "top" iohandler, which is the one that receives ^Cs, but still, I think that it should be possible to run everything "synchronously" and I hope that would get us rid of a lot of complexity.) Repository: rG LLVM Github Monorepo 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
