[Lldb-commits] [PATCH] D79654: [lldb/Driver] Support terminal resizing

[Frederic Riss via Phabricator via lldb-commits]

friss added a comment.

In D79654#2029131 <https://reviews.llvm.org/D79654#2029131>, @labath wrote:

> Yes, resizing the window (or doing any other nontrivial task) from within a signal handler is a bad idea. Making a note of the signal and then bailing out is the right approach. Though, to be fully strictly correct, the variable ought to be a `volatile std::sig_atomic_t` instead of a plain bool. This still won't make the whole thing async-signal-safe (I haven't inspected the whole SIGWINCH call stack, but I am sure there are still some unsafe operations there), but it's a step towards that.


I updated the patch with this change. I'll commit it tomorrow unless you can explain this:

> 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`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79654