如果你用类似source insight之类的代码阅读工具跟踪一下代码调用顺序，会很容易发现对于异步模式，Open()函数会在一系列辅助操作之后，进入函数uv_fs_open(),并且传入了一个FSReqWrap的对象。
FSReqWrap()，从名字可以看得出来，这是一个wrap,且是与FS相关的请求。也就是说，它基于某一个现成的机制来实现与FS相关的请求操作。这个现成的机制就是ReqWrap。好吧，它也是个wrap。乘你还没疯的时候，看一下图6吧。这里完整展示了FSReqWrap类继承关系。
除了FSReqWrap，还有其它Wrap,例如PipeConnectWrap，TCPConnectWrap等等。每个Wrap均为一种请求类型服务。 但是这些wrap，都是node自身的行为，而与libuv相关的是什么呢？上图中表示出了FSReqWrap关键的数据结构 uv_fs_s req__。
让我们把目光回到uv_fs_open()。在调用这个函数时， req__作为其一个重要的参数被传递进去。而在uv_fs_open()内部，req__则被添加到work queue的末尾中去。图3 thread pool中的thread会去领取这些request进行处理。 每个request很像一个粘贴板，它将event loop, work queue，每个请求的处理函数(work())，以及请求结束处理函数(done())绑定在一起。绑定的操作在uv__work_submit()中完成。 例如对于这里的req__，绑定在它身上的work()为uv__fs_work(), done()为uv__fs_done()。
这里有一个比较有意思的问题值得额外看一下。我们的thread pool是在什么时候建立的呢？
答案是：在第一次异步调用uv__work_submit()时。
每个thead的入口函数是 Threadpool.c中的worker()。工作逻辑比较简单，依次取出work queue中的请求，执行绑定在该请求上的work()函数。 前面我们提到的绑定在请求上的done()函数在哪里执行呢？这也是一个比较有意思的操作。libuv通过uv_async_send()通知event loop去执行相应的callback函数，也即我们绑定在request上的done()函数。uv__work_done()用于完成这样的操作。
uv_async_send()与主线程之间通过PIPE通信。
我在这一小节以一个FSReqWrap以及Open()函数为例，描述了libuv处理这种File I/O请求时所涉及的各种操作：
建立thread pool(只建立一次) 在每个请求req__上绑定与其相关的event loop, work queue, work(), done() thread worker()用来处理work queue里面的每个请求，并执行work() 通过uv_async_send()通知event loop执行done()
以上就是关于本次相关的知识点内容，感谢大家对软件开发网的支持。
