[gevent源代码分析] 深度分析gevent执行流程
一直对gevent执行流程比較模糊,近期看源代码略有所得。不敢独享。故分享之。
gevent是一个高性能网络库,底层是libevent,1.0版本号之后是libev。核心是greenlet。gevent和eventlet是亲近,唯一不同的是eventlet是自己实现的事件驱动。而gevent是使用libev。
两者都有广泛的应用,如openstack底层网络通信使用eventlet。goagent是使用gevent。
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQveXVlZ3VhbmdoYWlkYW8=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" alt="" />
或许大家会好奇,为什么採用这样的模式,为什么每次都要切换到hub?我想理由有二:
1.hub是事件驱动的核心,每次切换到hub后将继续循环事件。假设在一个greenlet中不出来,那么其他greenlet将得不到调用。
2.维持两者关系肯定比维持多个关系简单。每次我们所关心的就是hub以及当前greenlet。不须要考虑各个greenlet之间关系。
我们看看最简单的gevent.sleep发生了什么?
我们先想想最简单的sleep(0)该怎样调度?依据上面非常明显
1.向事件循环注冊当前greenlet的switch函数
2.切换到hub。执行主事件循环
def sleep(seconds=0, ref=True):
hub = get_hub()
loop = hub.loop
if seconds <= 0:
waiter = Waiter()
loop.run_callback(waiter.switch)
waiter.get()
else:
hub.wait(loop.timer(seconds, ref=ref))
当seconds小于等于0时。loop.run_callback(waiter.switch)即是将当前greenlet的switch注冊到loop。使用waiter.get()切换到hub。
那么非常明显,
当切换到hub后当调用刚注冊的回调(waiter.switch)回到刚刚sleep所在的greenlet。
不熟悉Waiter的童鞋可能对上面说的有点模糊,以下我们好好看看Waiter是什么。
>>> result = Waiter()
>>> timer = get_hub().loop.timer(0.1)
>>> timer.start(result.switch, 'hello from Waiter')
>>> result.get() # blocks for 0.1 seconds
'hello from Waiter'
timer.start(result.switch, 'hello from Waiter')我们向hub的主循环注冊一个0.1s的定时器,回调为result.switch,然后将执行result.get(),此时过程代码例如以下:
def get(self):
assert self.greenlet is None, 'This Waiter is already used by %r' % (self.greenlet, )
self.greenlet = getcurrent()
try:
return self.hub.switch()
finally:
self.greenlet = None
将把self.greenlet设置为当前greenlet,然后通过self.hub.switch()切换到主循环。非常明显在主循环中将回调result.switch,看代码:
def switch(self, value=None):
"""Switch to the greenlet if one's available. Otherwise store the value."""
greenlet = self.greenlet
assert getcurrent() is self.hub, "Can only use Waiter.switch method from the Hub greenlet"
switch = greenlet.switch
try:
switch(value)
except:
self.hub.handle_error(switch, *sys.exc_info())
拿到刚保存的greenlet。然后切换到greenlet.switch(),返回到我们刚调用reuslt.get()方法。通过上面assert我们也能够看出这是在hub中调用的。
通过以上分析,小伙伴们肯定都懂了gevent的执行流程了。
这里有个问题,假设上面先发生result.switch,那又该怎样呢?就像以下这样:
>>> result = Waiter()
>>> timer = get_hub().loop.timer(0.1)
>>> timer.start(result.switch, 'hi from Waiter')
>>> sleep(0.2)
>>> result.get() # returns immediatelly without blocking
'hi from Waiter'
我想聪明的你。打开hub.py再看看源代码肯定就明确了(上面Waiter代码是我特意简化的)。
既然我们知道了gevent执行流程,以下我们看看gevent.spawn和join究竟做了什么?
gevent.spawn事实上就是Greenlet.spawn,所以gevent.spawn就是创建一个greenlet,并将该greenlet的switch()加入hub主循环回调。
class Greenlet(greenlet):
"""A light-weight cooperatively-scheduled execution unit.""" def __init__(self, run=None, *args, **kwargs):
hub = get_hub()
greenlet.__init__(self, parent=hub)
if run is not None:
self._run = run
self._start_event = None def start(self):
"""Schedule the greenlet to run in this loop iteration"""
if self._start_event is None:
self._start_event = self.parent.loop.run_callback(self.switch) @classmethod
def spawn(cls, *args, **kwargs):
"""Return a new :class:`Greenlet` object, scheduled to start. The arguments are passed to :meth:`Greenlet.__init__`.
"""
g = cls(*args, **kwargs)
g.start()
return g
通过以下代码证明:
import gevent def talk(msg):
print(msg) g1 = gevent.spawn(talk, 'bar')
gevent.sleep(0)
将输出:bar,我们通过sleep切换到hub。然后hub将执行我们加入的回调talk。一切正常。
此时不要沾沾自喜,假设以下代码也认为一切正常再高兴也不迟。
import gevent def talk(msg):
print(msg)
gevent.sleep(0)
print msg g1 = gevent.spawn(talk, 'bar')
gevent.sleep(0)
这次还是输出:bar。有点不正确劲啊,应该输出两个bar才对,为什么为导致这样呢?
我们来好好分析流程:
1.gevent.spawn注冊回调talk
2.然后最后一行gevent.sleep(0)注冊当前greenlet.switch(最外面的)到hub。然后切换到hub
3.hub执行回调talk,打印"bar"。此时gevent.sleep再次将g1.switch注冊到hub,同一时候切换到hub
4.由于第2步最外层greenlet现注冊,所以将调用最外层greenlet,此时非常明显,程序将结束。
由于最外层greenlet并非hub的子greenlet。
所以died后并不会回到父greenlet,即hub
你可能会说那我自己手动切换到hub不就能够了吗?这将导致主循环结束不了的问题。
import gevent def talk(msg):
print(msg)
gevent.sleep(0)
print msg g1 = gevent.spawn(talk, 'bar')
gevent.get_hub().switch()
程序输出:
bar
bar
Traceback (most recent call last):
File "F:\py_cgi\geve.py", line 9, in <module>
gevent.get_hub().switch()
File "C:\Python26\lib\site-packages\gevent\hub.py", line 331, in switch
return greenlet.switch(self)
gevent.hub.LoopExit: This operation would block forever
尽管成功的输出了两次“bar"。但也导致了更为严重的问题。
这也就是join存在的价值,我们看看join是怎样做到的?
def join(self, timeout=None):
"""Wait until the greenlet finishes or *timeout* expires.
Return ``None`` regardless.
"""
if self.ready():
return
else:
switch = getcurrent().switch
self.rawlink(switch)
try:
t = Timeout.start_new(timeout)
try:
result = self.parent.switch()
assert result is self, 'Invalid switch into Greenlet.join(): %r' % (result, )
finally:
t.cancel()
except Timeout:
self.unlink(switch)
if sys.exc_info()[1] is not t:
raise
except:
self.unlink(switch)
raise def rawlink(self, callback):
"""Register a callable to be executed when the greenlet finishes the execution. WARNING: the callable will be called in the HUB greenlet.
"""
if not callable(callback):
raise TypeError('Expected callable: %r' % (callback, ))
self._links.append(callback)
if self.ready() and self._links and not self._notifier:
self._notifier = self.parent.loop.run_callback(self._notify_links) def _notify_links(self):
while self._links:
link = self._links.popleft()
try:
link(self)
except:
self.parent.handle_error((link, self), *sys.exc_info())
从代码中能够看出,join会保存当前greenlet.switch到一个队列中,并注冊_notify_links回调,然后切换到hub。在_notify_links回调中将依次调用先前注冊在队列中的回调。
而我们调用g1.join()将会把最外层greenlet.switch注冊到队列中,当回调时就顺利结束程序了。
非常完美!!!
[gevent源代码分析] 深度分析gevent执行流程的更多相关文章
- 转:[gevent源码分析] 深度分析gevent运行流程
[gevent源码分析] 深度分析gevent运行流程 http://blog.csdn.net/yueguanghaidao/article/details/24281751 一直对gevent运行 ...
- angularjs源码分析之:angularjs执行流程
angularjs用了快一个月了,最难的不是代码本身,而是学会怎么用angular的思路思考问题.其中涉及到很多概念,比如:directive,controller,service,compile,l ...
- debian下使用dynamic printk分析usb转串口驱动执行流程
看了一篇文章<debug by printing>,文中提到了多种通过printk来调试驱动的方法,其中最有用的就是"Dynamic debugging". “Dyna ...
- 从 mian 函数开始一步一步分析 nginx 执行流程(二)
如不做特殊说明,本博客所使用的 nginx 源码版本是 1.0.14,[] 中是代码所在的文件! 上一个博客中我们将 main 函数执行流程分析完,到最后一步调用 ngx_master_process ...
- angularjs执行流程
angularjs源码分析之:angularjs执行流程 angularjs用了快一个月了,最难的不是代码本身,而是学会怎么用angular的思路思考问题.其中涉及到很多概念,比如:directi ...
- 【高并发】通过源码深度分析线程池中Worker线程的执行流程
大家好,我是冰河~~ 在<高并发之--通过ThreadPoolExecutor类的源码深度解析线程池执行任务的核心流程>一文中我们深度分析了线程池执行任务的核心流程,在ThreadPool ...
- Monkey源代码分析之执行流程
在<MonkeyRunner源代码分析之与Android设备通讯方式>中.我们谈及到MonkeyRunner控制目标android设备有多种方法.当中之中的一个就是在目标机器启动一个mon ...
- spark-sql执行流程分析
spark-sql 架构 图1 图1是sparksql的执行架构,主要包括逻辑计划和物理计划几个阶段,下面对流程详细分析. sql执行流程 总体流程 parser:基于antlr框架对 sql解析,生 ...
- Flink 源码解析 —— Standalone Session Cluster 启动流程深度分析之 Job Manager 启动
Job Manager 启动 https://t.zsxq.com/AurR3rN 博客 1.Flink 从0到1学习 -- Apache Flink 介绍 2.Flink 从0到1学习 -- Mac ...
随机推荐
- Jquery 实现轮播图
jq 轮播图 function banner_show(){ var left_btn = $("#banner_tag_left"); //获取左侧单击按钮 var right_ ...
- 第六章:加载或保存JSON数据
加载或保存JSON数据 Knockout可以实现很复杂的客户端交互,但是几乎所有的web应用程序都要和服务器端交换数据(至少为了本地存储需要序列化数据),交换数据最方便的就是使用JSON格式 – 大多 ...
- Java Script 基础
一. JS的简介 JavaScript是一种网页编程技术,经常用于创建动态交互网页 JavaScript是一种基于对象和事件驱动的解释性脚本语言,类似C语言和Java的语法 事先不编译:逐行执行:无需 ...
- list容器详解
首先说说STL ( STL的目的是标准化组件,这样就不用重新开发,可以使用现成的组件.STL现在是C++的一部分,因此不用额外安装什么.它被内建在你的编译器之内.因为STL的list是一个简单的容器, ...
- SSMdemo:租房管理系统
使用ssm框架整合,oracle数据库 框架: Spring SpringMVC MyBatis 导包: 1, spring 2, MyBatis 3, mybatis-spring 4, fastj ...
- 连接LilyPad之Linux平台的驱动
连接LilyPad之Linux平台的驱动 常用的Linux发行版都自带了FTDI驱动,因此在绝大多数Linux发行版中不需要用户进行额外的操作. 在LilyPad编程器被正确驱动后,就可以将LilyP ...
- Cpp下的深拷贝与浅拷贝探究
下面,通过代码来说说C++中的深浅拷贝 #define _CRT_SECURE_NO_WARNINGS #include<iostream> using namespace std; cl ...
- 「CSA49」Bunny on Number Line
「CSA49」Bunny on Number Line 题目大意:有一个人从0开始走,每次可以向前走一步或者回到1,那么会产生一个位置序列,其中给出 \(k\) 个位置是好的.定义一个位置序列是好的, ...
- [NOI2007]货币兑换 --- DP + 斜率优化(CDQ分治)
[NOI2007]货币兑换 题目描述: 小 Y 最近在一家金券交易所工作.该金券交易所只发行交易两种金券:A 纪念券(以下简称 A 券)和 B 纪念券(以下简称 B 券). 每个持有金券的顾客都有一个 ...
- [Codeforces #172] Tutorial
Link: Codeforces #172 传送门 A: 一眼看上去分两类就可以了 1.每个矩形只有两条边相交,重合的形状为菱形 2.每个矩形四条边都有相交 对于情况1答案为$h*h/sin(a)$ ...