You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
0 commit comments