ffi-napi async()与worker_threads调用DLL回调差异原因咨询

核心原因拆解 #

1. ffi-napi async() 调用的工作机制 #

ffi-napi的async()方法会把DLL函数的执行卸载到libuv的线程池线程中，和Electron主线程的事件循环完全隔离：

• DLL的while循环+sleep逻辑在独立的线程池线程中持续运行，不会阻塞主线程的UI渲染或事件处理。
• 每次DLL触发JS回调时，ffi-napi会通过libuv的异步队列，将回调任务投递到主线程的事件循环中执行，确保V8引擎能正确处理回调函数，因此每3秒的回调都能正常触发。

2. worker_threads同步调用的问题所在 #

当你在手动创建的worker线程中同步调用DLL函数时，DLL的执行会直接占用worker线程的主线程：

• worker线程的事件循环被DLL的while循环+sleep完全阻塞——worker线程的主线程一直卡在DLL的执行逻辑里，没有机会处理自身事件循环中的任务队列。
• 第一次回调能触发，是因为DLL首次调用回调时，worker线程还未被完全阻塞；但后续DLL再调用回调时，worker的事件循环已经无法周转，V8无法处理新的回调任务，所以看起来回调停止了（实际DLL仍在后台循环，只是回调无法被执行）。

两种方案的核心差异 #

修复建议 #

在worker线程中，同样使用ffi-napi的async()方法调用DLL函数，而非同步调用。这样DLL的执行会被卸载到libuv线程池，worker线程的事件循环不会被阻塞，回调任务能正常被worker的事件循环调度执行，就能实现和主线程调用一致的效果。

内容的提问来源于stack exchange，提问作者최원상