1. The essence of IO operation
No CPU consumption during data copying
# 1 内存分为内核缓冲区和用户缓冲区
# 2 用户的应用程序不能直接操作内核缓冲区，需要将数据从内核拷贝到用户才能使用
# 3 而IO操作、网络请求加载到内存的数据一开始是放在内核缓冲区的
Second, the IO model
-
BIO-blocking mode I / O
The user process suspends waiting from initiating the request until it finally gets the data; the data will be copied by the user process
'''
举个例子：一个人去 商店买一把菜刀，
他到商店问老板有没有菜刀（发起系统调用）
如果有（表示在内核缓冲区有需要的数据）
老板直接把菜刀给买家（从内核缓冲区拷贝到用户缓冲区）
这个过程买家一直在等待
如果没有，商店老板会向工厂下订单（IO操作，等待数据准备好）
工厂把菜刀运给老板（进入到内核缓冲区）
老板把菜刀给买家（从内核缓冲区拷贝到用户缓冲区）
这个过程买家一直在等待
是同步io
'''
-
NIO-Non-blocking mode I / O
The user process initiates a request, if the data is not ready, then immediately inform the user that the process is not ready; at this time, the user process can choose to continue to initiate the request, or to do other things first, and then come back to continue to send the request later, until being informed of data preparation When finished, you can start receiving; the data will be copied by the user process
'''
举个例子：一个人去 商店买一把菜刀，
他到商店问老板有没有菜刀（发起系统调用）
老板说没有，在向工厂进货（返回状态）
买家去别地方玩了会，又回来问，菜刀到了么（发起系统调用）
老板说还没有（返回状态）
买家又去玩了会（不断轮询）
最后一次再问，菜刀有了（数据准备好了）
老板把菜刀递给买家（从内核缓冲区拷贝到用户缓冲区）
整个过程轮询+等待：轮询时没有等待，可以做其他事，从内核缓冲区拷贝到用户缓冲区需要等待
是同步io
'''
-
IO Multiplexing-I / O multiplexing model
Similar to BIO, just find an agent to suspend waiting, and can listen to multiple requests at the same time; the data will be copied by the user process
'''
举个例子：多个人去 一个商店买菜刀，
多个人给老板打电话，说我要买菜刀（发起系统调用）
老板把每个人都记录下来（放到select中）
老板去工厂进货（IO操作）
有货了，再挨个通知买到的人，来取刀（通知/返回可读条件）
买家来到商店等待，老板把到给买家（从内核缓冲区拷贝到用户缓冲区）
多路复用：老板可以同时接受很多请求（select模型最大1024个，epoll模型），
但是老板把到给买家这个过程，还需要等待，
是同步io
'''
-
AIO-Asynchronous I / O model
Initiate the request to get a response immediately, without waiting to wait; the data will be automatically copied by the kernel process
'''
举个例子：还是买菜刀
现在是网上下单到商店（系统调用）
商店确认（返回）
商店去进货（io操作）
商店收到货把货发个卖家（从内核缓冲区拷贝到用户缓冲区）
买家收到货（指定信号）
整个过程无等待
异步io
'''
3. Synchronous I / O and asynchronous I / O
- Synchronous I / O
- Concept: I / O operation that causes the request process to block until the I / O operation task is completed
- Type: BIO, NIO, IO Multiplexing
- Asynchronous I / O
- Concept: I / O operations that do not cause the process to block
- Type: AIO
note:
- The judgment basis of synchronous I / O and asynchronous I / O is whether it will cause the user process to block
- The socket in BIO directly blocks and waits (the user process actively waits and waits when copying)
- Blocked when copying data from kernel space to user space in NIO (user process actively asks and waits while copying)
- The select and other functions in IO Multiplexing are blocked, and are blocked when copying data (the user process waits actively and also waits when copying)
- AIO user processes are not blocked from beginning to end (user processes are passive)
Four, IO design pattern
Reactor模式，基于同步I/O实现
- Proactor模式，基于异步I/O实现
Reactor mode is usually implemented using IO multiplexing mechanism
- kqueue、epoll、poll、select等机制
Proactor mode is usually implemented using the asynchronous mechanism of OS Asynchronous IO (AIO)
- 前提是对应操作系统支持AIO，比如支持异步IO的linux(不太成熟)、具备IOCP的windows server(非常成熟)
Both Reactor mode and Proactor mode are event-driven, and the main implementation steps are:
- Event registration: Separate events from event handlers. Register the event in the event loop, manage the event processor separately, and record its correspondence with the event.
- Event monitoring: start the event loop and notify the event handler as soon as the event is ready / completed
- Event distribution: When the event ready / complete signal is received, the event handler corresponding to it is immediately activated
- Event handling: execute event handlers in processes / threads / coroutines
During use, users are usually only responsible for defining and registering events and event handlers and starting the event loop at the beginning . This process will execute tasks in an asynchronous manner.
Reactor mode
Proactor mode
Comparative analysis
Reactor model processing time-consuming operations will cause event distribution blocking, affecting the processing of subsequent events;
The implementation logic of the Proactor model is complex; relying on the operating system's support for asynchrony, there are currently few operating systems that implement pure asynchronous operations, and excellent ones such as windows IOCP, but due to the limitations of their windows system for servers, the current application range is small; The Unix / Linux system has limited support for pure asynchronous, so the mainstream of application event-driven is still based on the reactor mode implemented by select / epoll, etc.
In Python: asynchronous modules such as asyncio, gevent, tornado, twisted, etc. are designed based on the event-driven model, and more are using the reactor model, some of which also support the proactor mode, of course, you need to manually according to the current operating system environment Configuration