Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
While the performance of tpipeline itself has been optimized quite a while for now, it is still possible for a bottleneck to appear, if the downstream consumer is too slow. The problem does not really show up when using tmux, but when using other external integrations (e.g. kitty), it is possible that the external statusline update can become a bottleneck. Kitty's custom tabbar integration being written in Python does not really help with this. It should be noted that this has never caused any delays in vim itself, given that this bottleneck only happens in the part, that is already running completely asynchronous from vim itself. But it could cause some hilarious problems, where the external statusline starts to lag behind noticably behind the live statusline in vim. To fix this we batch updates by depleting stdin completely before dispatching the external statusline update. Unfortunately there is not really a very good way to test if stdin contains more data just with shell code. We opt to use a hack with "read -t", which will fail immediately if stdin is empty: -t timeout time out and return failure if a complete line of input is not read within TIMEOUT seconds. The value of the TMOUT variable is the default timeout. TIMEOUT may be a fractional number. If TIMEOUT is 0, read returns immediately, without trying to read any data, returning success only if input is available on the specified file descriptor. The exit status is greater than 128 if the timeout is exceeded This is a complete hack, because "-t" is not really portable across sh implementations, e.g. the slightly widely used dash does not support it. We are very lucky with this specific codepath though, because "sh does not support -t" and "there is no more stdin data ready" have the same exit code, thus sh implementations not supporting this flag will automatically fallback to the old unbatched update path, i.e. they will never enter the inner while loop. If this however still ever causes problems in the future, we could think about using bash instead of sh. Both are basically preinstalled everywhere anyway. With this we can also lower the catchup time in the performance test, as the lagging behind is completely fixed now. In any case this also adds a completely new unit test that tests the lag-behind after updating the statusline every millisecond for 3 seconds. Fixes #64
- Loading branch information