From 5e569a47031d2a5b94cfadd67d5e76ba4651ac4d Mon Sep 17 00:00:00 2001 From: bfredl Date: Tue, 25 Apr 2023 13:39:28 +0200 Subject: refactor(fs): now it is time to get rid of fs_loop and fs_loop_mutex Here's the headline: when run in sync mode (last argument cb=NULL), these functions don't actually use the uv_loop_t. An earlier version of this patch instead replaced fs_loop with using main_loop.uv on the main thread and luv_loop() on luv worker threads. However this made the code more complicated for no reason. Also arbitrarily, half of these functions would attempt to handle UV_ENOMEM by try_to_free_memory(). This would mostly happen on windows because it needs to allocate a converted WCHAR buffer. This should be a quite rare situation. Your system is pretty much hosed already if you cannot allocate like 50 WCHAR:s. Therefore, take the liberty of simply removing this fallback. In addition, we tried to "recover" from ENOMEM in read()/readv() this way which doesn't make any sense. The read buffer(s) are already allocated at this point. This would also be an issue when using these functions on a worker thread, as try_to_free_memory() is not thread-safe. Currently os_file_is_readable() and os_is_dir() is used by worker threads (as part of nvim__get_runtime(), to implement require from 'rtp' in threads). In the end, these changes makes _all_ os/fs.c functions thread-safe, and we thus don't need to document and maintain a thread-safe subset. --- test/unit/helpers.lua | 1 - 1 file changed, 1 deletion(-) (limited to 'test/unit/helpers.lua') diff --git a/test/unit/helpers.lua b/test/unit/helpers.lua index 8fa6378d10..52769cd9e9 100644 --- a/test/unit/helpers.lua +++ b/test/unit/helpers.lua @@ -97,7 +97,6 @@ local init = only_separate(function() for _, c in ipairs(child_calls_init) do c.func(unpack(c.args)) end - libnvim.fs_init() libnvim.event_init() libnvim.early_init(nil) if child_calls_mod then -- cgit