diff options
author | bfredl <bjorn.linse@gmail.com> | 2023-04-23 19:02:23 +0200 |
---|---|---|
committer | bfredl <bjorn.linse@gmail.com> | 2023-04-24 17:38:19 +0200 |
commit | 0d2fe7786537ef63d0d3ed1e94546eb3ee35a368 (patch) | |
tree | f479da09da4436af82dc015646ab519556c81750 /runtime/lua/vim/re.lua | |
parent | 3ac952d4e27f4e2454332a730310316fe13fd4a3 (diff) | |
download | rneovim-0d2fe7786537ef63d0d3ed1e94546eb3ee35a368.tar.gz rneovim-0d2fe7786537ef63d0d3ed1e94546eb3ee35a368.tar.bz2 rneovim-0d2fe7786537ef63d0d3ed1e94546eb3ee35a368.zip |
refactor(time): refactor delay with input checking
Previously, there were three low-level delay entry points
- os_delay(ms, ignoreinput=true): sleep for ms, only break on got_int
- os_delay(ms, ignoreinput=false): sleep for ms, break on any key input
os_microdelay(us, false): equivalent, but in μs (not directly called)
- os_microdelay(us, true): sleep for μs, never break.
The implementation of the latter two both used uv_cond_timedwait()
This could have been for two reasons:
1. allow another thread to "interrupt" the wait
2. uv_cond_timedwait() has higher resolution than uv_sleep()
However we (1) never used the first, even when TUI was a thread, and
(2) nowhere in the codebase are we using μs resolution, it is always a ms
multiplied with 1000.
In addition, os_delay(ms, false) would completely block the thread for
100ms intervals and in between check for input. This is not how event handling
is done alound here.
Therefore:
Replace the implementation of os_delay(ms, false) to use
LOOP_PROCESS_EVENTS_UNTIL which does a proper epoll wait with a timeout,
instead of the 100ms timer panic.
Replace os_microdelay(us, false) with a direct wrapper of uv_sleep.
Diffstat (limited to 'runtime/lua/vim/re.lua')
0 files changed, 0 insertions, 0 deletions