friss added a comment. In D79654#2030635 <https://reviews.llvm.org/D79654#2030635>, @friss wrote:
> > If we wanted to avoid delaying the change to the next keystroke, we could > > reuse the same mechanism that ^C/SIGINT uses > > (`m_input_connection.InterruptRead()`). That would probably require > > introduction of a new `EditorStatus` enum, and a careful modification to > > the code handling the input interruption. I don't expect that to be _too_ > > hard, but I also don't think that's required for this change. > > I gave this a try, and indeed the changes do not seem too involved, but > there's a bunch of details I don't get. `Editline::Interrupt()` and > `Editline::Cancel()` take `m_output_mutex` before interrupting. If I do a > similar thing in a resize handler, I don't see what prevents the signal to be > delivered while the lock is held by `GetLines` but before it is released in > `GetCharacter`. Sorry, this really wasn't clear... let's try again with more words: The mutex in `Editline::Interrupt()` and `Editline::Cancel()` make it look like there's a need for synchronization (`m_output_mutex`) before calling `m_input_connection.InterruptRead()`. However those methods cannot be called on the same thread, or they have a chance to deadlock. I actually don't see how `sigint_handler` in `Driver.cpp` is correct in this regard. I suppose we put the terminal in raw mode and thus do not generate SIGINT on Ctrl-C. But it seems like an externally sent SIGINT could deadlock the driver pretty easily. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D79654/new/ https://reviews.llvm.org/D79654 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
