libuv callbacks vs. job processes for non-blocking CPU-bound Lua tasks

Maintaining UI responsiveness in Neovim during heavy computation requires choosing between event-loop-based callbacks and external process management. Since Neovim utilizes a single-threaded event loop for Lua execution, any synchronous task performed on the main thread will result in immediate input latency.

Using vim.loop (libuv) primitives allows for non-blocking operations, but callbacks are ultimately scheduled back on the main thread. This approach does not solve latency for CPU-intensive tasks, as the UI remains blocked while the callback executes.

Alternatively, vim.job_start enables true concurrency by offloading work to external processes. While this prevents the UI from freezing, it introduces overhead due to MessagePack serialization when passing large datasets across the RPC-C boundary.

• At what data volume or complexity threshold does the synchronization overhead of vim.loop.schedule exceed the serialization cost of vim.job_start?
• What are the recommended patterns for state synchronization when using external processes to avoid race conditions on the main loop?