[Lldb-commits] [PATCH] D79654: [lldb/Driver] Support terminal resizing
Frederic Riss via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Mon May 11 19:59:41 PDT 2020
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
More information about the lldb-commits
mailing list