Event Loop
- Event Loop模式
-
-
- 什么是同步、异步、阻塞、非阻塞?
-
-
-
- 消息通信机制层面理解:同步 or 异步
- 程序调用层面理解:阻塞 or 非阻塞
- 操作系统层面理解:同步 or 异步,阻塞 or 非阻塞
- 操作系统I/O模型演进:
- 如何理解I/O多路复用?
- I/O 多路服用有多种实现模式:select、 poll、 epoll、 kqueue
- 信号驱动 IO:从轮询查看数据是否就绪(I/O多路复用)变为 消息异步通讯。你好了你再告诉我,给我个信号就行啦!
- 异步 IO 模型:异步 I/O 模型是目前最理想的一种形式,应用程序发起系统调用后无需等待直接返回当前调用状态,进行后续的其它任务,结果由内核完成 I/O 操作之后通过回调通知到我们的应用程序,中间没有阻塞过程。
-
-
- 什么是Event Loop模式?事件轮询。
- JS中EventLoop应用
- EventLoop与Poll的关系?
- Reference
-
Event Loop模式
什么是同步、异步、阻塞、非阻塞?
- 如果所有的调用都是立即返回结果,不存在执行等待(I/O通信->执行等待,资源等待->服务挂起),就不需要异步和阻塞。
- 同步/异步:主要体现在调用方发起请求后,是自己主动探查结果反馈(同步),还是被动由服务提供方告知反馈结果(异步)。
- 阻塞/非阻塞:主要体现在调用方发起请求后,在等待结果反馈期间,是原地不动(阻塞),还是统筹时间干别的事情去(非阻塞)。
消息通信机制层面理解:同步 or 异步
同步:调用方调用,调用方主动询问。(调用方一会儿一问:“完事没啊?”
)
异步:调用方调用,返回结果以(回调callback、状态或者通知)方式由服务提供方告知调用方。(调用方:“完事告诉我哈!”
)
程序调用层面理解:阻塞 or 非阻塞
阻塞:调用方的线程request在等待反馈结果期间被挂起(啥也不干了),调用方得到response,再唤醒被挂起的线程,该唤醒过程可能是服务提供方以回调的方式唤醒的。(调用方:“啥也不干,干等你!”
)
非阻塞:调用方的线程request在等待结果期间不会被挂起(可以干别的),直到response后才返回。(调用方:“老子忙别的去了!”
)
- 同步阻塞I/O:调用方请求后,一直等待结果,不干别的。
- 同步非阻塞I/O:调用方请求后,一边去吃鸡了(干别的事儿),一边不断询问(完事儿没)。
- 异步阻塞I/O:调用方请求后,也不干别的,也不询问。服务提供方完成之后,主动告知调用方。
- 异步非阻塞I/O:调用方请求后,万事大吉,一边去吃鸡了(干别的事儿)。服务提供方完成之后,主动告知调用方。
操作系统层面理解:同步 or 异步,阻塞 or 非阻塞
同步:应用层向系统内核发起请求,不断盲目询问:“完事儿没?”,直到完事儿了。
异步:应用层向系统内核发起请求,走了不管了,系统内核完成操作后主动告知应用层:“完事儿了哈!”
阻塞:应用层向系统内核发起I/O请求,被挂起,盲目傻傻等待,直到完事儿了。
非阻塞:应用层向系统内核发起I/O请求,干别的去了。