|
目前我通libuv（windows） 的学习、调试了 fs，tcp,queue_work,async 四大模块，发现如下： 1、libuv 的事件机制都时基于 IOCP 的，具体如下： 在初始化 uv_loop_t * loop时，如 loop = uv_default_loop();通过CreateIoCompletionPort 创建了IOCP handle。 在线程中调用uv_run 函数进行 GetQueuedCompletionStatus 查询相关的各种请不完成情况，如UV_READ，UV_ACCEPT，UV_CONNECT 等TCP相关的操作请求。同时处理 文件读写、线程操作完成、ansync 请求都时能过PostQueuedCompletionStatus API 模拟 IO完成的，产生UV_WAKEUP 请求。 通过以上可以得知，所以IO操作，文件操作，线程池调度 都是统一用 IOCP的机制进行的。 2、fs 模块中，读写文件一块并没有将文件handle 挂接到IOCP handle中，而是通过建立线程池，将所以文件操作通过线程池中线程同步操作的，线程完成后，通过PostQueuedCompletionStatus API 模拟 IO完成，产生UV_WAKEUP 请求完成。最终通过 uv_run 来调度的。 3、tcp 模块，所有socket 都是 调用CreateIoCompletionPort 完成与IOCP的挂接，通过windows 的异步API 投送操作请求，如WSARecv。注意创建IOCP时，CreateIoCompletionPort 的NumberOfConcurrentThreads 值为1，标明IOCP中，只有一个 活动线程进行监听。libuv中并没有创建线程池来GetQueuedCompletionStatus ，需求调用 uv_run 进行监听。可以自己产生多线程进行调用 uv_run 进行高并发监听。 4、queue_work 线程池（fs 中也是用了类似的线程池），在调用 uv_queue_work 时，产生4个线程，并将用户线程函数提交给空闲线程处理，线程处理完成后，通过PostQueuedCompletionStatus API 模拟 IO完成，产生UV_WAKEUP 请求完成。由于un_run 完成调度。 5、async 线程间通信机制，通过 uv_async_init 初始一个 async 对象并于IOCP挂接，产生一个UV_WAKEUP请求。在别外的线程中通过 uv_async_send(&async)，通过PostQueuedCompletionStatus API 模拟 IO完成，在接收线程由un_run 完成调度。 其他待后续。。。。
|
|
|
