0x55aa的博客

昨天下午写了一个postgresql访问接口库psycopg2的异步封装，这个库是支持异步请求postgresql的，所以只是简单的封装了一下。简介了torndb和一个网上写好的异步库momoko，又找到一个网上分享的ppt。写的时候直接用gen.coroutine装饰接口函数，这样我再models里写的时候直接yield query()就行了。 写完对tornado异步封装的代码也看了一些，有了一些理解，不过没有循序看。之前看到时候感觉太乱实在不想从新看了。先记录一下，可能很多错误。 future是保存的异步的结果，这个类是在concurrent.py文件里。 result()方法是返回结果，通过done()方法判断执行结束，就可以用result方法获得结果。 set_result()是设置结果，像gen.Task()就是调用一个带有callback参数的异步方法，返回future，变成为一个可以使用yield协程 的函数，对他就是个函数。2333 这个函数里边就使用了set_result()方法，Task这个函数其实不复杂写了那么多的目的就是把Task装饰的那个函数里边callback的参数用set_result()设置成返回值，保存在future里。哈哈 我觉得以后我看这里也不会看懂，还不如直接看代码容易。这里用到了带名字的元组，这个看到过没用过。set_result()用的地方很多 其他的基本就是异常处理， 先看看其他周边，想gen.Return是继承自Exception所以这个用raise，这个异常会在后边用的时候捕获到，然后当做结果。 其他的没看，代码没看全，没看到那些类和函数。 coroutine这个装饰器，内容很多。 先是执行函数，有返回值，保存，然后如果抛出Return exception 获取里边的值，或者其他程序异常。 没有异常，就判断结果是否是生成器，不是生成器直接将结果set_result保存到future并返回结果，如果是next执行之，如果执行完或者Return设置执行完的值，这里异常处理和上边一样，执行完后如果没有异常产生，执行Runner（），handler_yield没看，主要看了run(),处理方式基本相同，主要就是将刚刚执行的结果通过send方法返回给yield前边的变量，就是类似a = yield query()这种，将结果返回给a。 然后总结一下思路，可能不太对。requesthandler执行的时候，执行相对应的http method，如果返回的不是future，那ok，流程上边写过了，执行完没有异常并判断不是个生成器类型就会直接在future保存结果并返回。为什么还要保存到future中呢。因为requesthandler里的execute也是经过coroutine修饰过了。 发现返回一个future，因为比如一个get方法被我们用coroutine装饰了。然后他就yield，这个的返回结果就是你get方法的结果了。 然后执行对应的我的model里的search_result(),然后执行query语句，我都是用gen.Return返回的结果，怎么感觉这么复杂。。。感觉这样写不太对，不太符合设计 query方法先获取cursor，这些都是coroutine修饰的，都是返回的生成器类型。（之所以这样写，这个库只我自己用，我不喜欢callback的模式，感觉yield写起来也方便看起来也方便，封装的时候参数也不写callback了）使用gen.Task获取conn，为啥用这个因为这个必须设置callback，然后里边的callback参数就是conn，这样task会将装饰的函数参数callback的参数最终作为结果返回。这里说装饰也不太对，Task不是个装饰器。感觉跟functools里的partial很像，但不一样，他返回一个future。这样就会最终返回给我链接数据库的conn，在cursor我是用gen.Return返回corsors，这个会捕获到Return异常直接设置到future里当做结果，最后通过runner里的run返回给yield关键字前的cursor变量。这样就获取到了cousor。。。。。下边执行语句的时候和这个流程一样