This removes the global Sleep(1) workaround that was originally added to prevent memory leaks caused by tight polling loops.
While it helped with the mai2 memory leak, introducing artificial latency here negatively impacts other UART devices (e.g., breaking slider inputs in chusan). The proper fix has now been implemented downstream in `segatools` by rate-limiting the specific `led15070` board instead. Therefore, this global hack is no longer needed and can be safely removed.
Reviewed-on: https://gitea.tendokyu.moe/TeamTofuShop/capnhook/pulls/6
Co-authored-by: Gl0w1amp <gl0w1amp@noreply.gitea.tendokyu.moe>
Co-committed-by: Gl0w1amp <gl0w1amp@noreply.gitea.tendokyu.moe>
Added Sleep(1) to uart_handle_read when no data is available to simulate
hardware I/O latency. This prevents the hook from entering a tight polling
loop, which was causing high CPU usage and massive memory leaks.
The loop this commit removed tries to sleep and wait for the IO DLL
to write something to uart->readable. It doesn't work for two reasons:
1. When uart_handle_read() is sleeping, its caller holds the lock
for the resource, meaning nothing can be writen, and it always times out.
2. Even without the deadlock problem, due to timer resolution limit
on Windows, Sleep(1) does not actually sleep 1ms.
Instead it sleeps over 15ms by default.
The symptom is a noticable input lag, and lost inputs.
This commit tries to fix that.
Reviewed-on: https://gitea.tendokyu.moe/TeamTofuShop/capnhook/pulls/2
Co-authored-by: octocat <git.rascal570@passinbox.com>
Co-committed-by: octocat <git.rascal570@passinbox.com>
- If another DLL being loaded spawns a thread that begins doing I/O,
then there is a race condition where `hook_table_apply` is still
applying the hooks and has not returned yet but the hooked functions
are called by those other threads. This causes the assert on
`iohook_initted` to trigger.
- The easy fix is to always enter the mutex to ensure the hooks have
been applied and function addresses for `CreateFileW` and
`SetFilePointerEx` have been resolved.
The loaded module list is kept in the order the modules are first
loaded. Using the first loaded module (i.e. the EXE) will help
ensure that multiple hook DLLs stack correctly. Previously the link
was taken from the most-recently loaded module.