[Lldb-commits] [PATCH] D72748: [lldb/IOHandler] Change the way we manage IO handler

Jim Ingham via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Wed Jan 15 12:05:06 PST 2020


jingham added a comment.

In D72748#1822443 <https://reviews.llvm.org/D72748#1822443>, @clayborg wrote:

> So I did a bunch of original IOHandler. And there are many complex cases for sure. One thing to be aware of is that if you won't use editline() and we call fgets() in the default implementation, there is no way to cancel this IIRC. So it might be worth trying this without editline support to make sure things don't deadlock. If the test suite is happy, then this looks worth trying, though with all the complexities I don't think we can guarantee this doesn't cause issues in some unexpected way. The main things that worry me are:
>
> - REPL issues since the REPL and (lldb) prompt switch between themselves in a tricky way where they swap IOHandlers
> - running from python script directly when no IOHandlers are pushed because no command interpreter is being run and all the fallout from the cases (HandleCommand that results in a python breakpoint callback etc)
> - the process IO handler that does STDIO for a process
> - when no editline, we use fgets() that can't be canceled


The fgets part is problematic in other ways.  For instance, Python based commands in stop hooks work in command line lldb, but in Xcode which doesn't use editline, when we go to fflush the I/O channel on switching to the Python interpreter, fflush deadlocks against the lock held by fgets.  I wonder if we should just stop using fgets and use select everywhere we can, as it doesn't have this problem.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72748/new/

https://reviews.llvm.org/D72748





More information about the lldb-commits mailing list