Terminal resize roundtrip

Issue: Currently resizing the terminal control flow is done like this:

• terminal.resize triggered by some listener, which listens to grip movements (maybe with fit addon in between) or explicit col/row changes
• pty gets announced about size change by a sideway comm, this happens async and we dont wait for it to actually happen, basically we dont care when WINCH gets signalled
• buffers/views are resized (following a specific paradigm like reflow or simple cutting)

Since the pty resize happens async and we dont wait for it to happen there might be data in the buffers from pty to terminal that were written under the old size assumption. This is for most circumstances not a problem, most ASCII input flow scenarios will just work with this, but it might lead to garbage content lines if the slave application relies on the correct terminal size.

Solution: I think this race condition cannot be avoided completely, but narrowed to only a small buffer window by doing the following:

• terminal.resize gets triggered by some listener
• terminal sends a XOFF to the pty, thus “halts” any outputting slave program
• terminal drains all pending data from buffers inserting it with old size
• terminal announces new size to pty and waits for resize ACK
• pty signals WINCH
• on resize ACK:
  • buffers/views are resized
  • XON to reenable data flow

Here the XOFF guarantees that pending data are already written and ACK token ensures that the pty has applied the new size. Have not yet thought about this model in detail, maybe the XOFF full stop could be made less invasive by inserting the ACK token in the websocket stream, maybe the ACK token should even contain the applied size (in case the pty cannot set the requested size for some reason). This size roundtrip certainly would slow down data flow during heavy slave output/terminal input. Furthermore there still might be buffers involved that are not covered by XOFF and contain “wrongly sized” data, mainly on slave app side, like stdout FILE buffer. Not sure how libs like readline deal with buffered data on WINCH or if they always switch off any prebuffering.

Up for discussion, not sure if we should try to mess with this at all, for most scenarios it works good enough as it is now.

[jerch]

Made a tracking issue for that: #1918.

Gonna close this issue for now, since we have currently no viable way to control buffer drainage for proper size propagation.

[Tyriar]

@jerch could be useful for attach, might be best for someone who uses this case to tackle that one as there are downsides to tweaking this (and the best numbers may depend on latency?)