想看一下IOLoop类的实现，发现继承自Configurable。就先看一下这个类。 Configurable类在util.py这个文件里。Configurable类的子类有AsyncHTTPClient，Resolver，IOLoop。 看__new__构造方法，configurable_base返回一个子类的实现，如果返回类本身。类的实现需要调用configured_class，主要初始化了__impl_class在configurable_default里。然后通过子类中configurable_default的定义选择不同的__impl_class（类实现）返回。initialize初始化类。 然后没了 ，没想到这么短。等后边看看IOLoop。

记录，说不定以后还能用到。打jar包指定main程序入口

public class Hello{
    public static void main(String[] args){
        System.out.println("hello");
    }
}

java版helloworld。保存成Hello.java。执行 javac Hello.java会生成Hello.class jar cvf hello.jar Hello.class生成hello.jar 现在直接执行java -jar hello.jar会提示“hello.jar中没有主清单属性”要先指定程序入口 解压hello.jar，会看到/META-INF/MANIFEST.MF文件 Manifest-Version: 1.0 Created-By: 1.8.0_25 (Oracle Corporation) 加上两行 Class-Path: . Main-Class: Hello 执行 jar umfv MANIFEST.MF hello.jar 更新一下jar包里边的文件 执行java -jar hello.jar 成功显示hello。

github地址 https://github.com/0x55aa/pytoto 写不下去了，又开始写别的了 我去。 总是做着做着发现东西越来越多。

在django/conf/__init__.py里，最后一行，settings = LazySettings()。到LazySettings()，继承自LazyObject，django/utils/functional.py里，初始化的时候self._wrapped为object()。LazyObject也设置了__getattr__，不过差不多。回头看LazySettings的__getattr__，开始要执行_setup，然后使用getattr取值。 ---- def _setup(self, name=None): settings_module = os.environ[ENVIRONMENT_VARIABLE]，这个在wsgi脚本，或者在manage.py里有设置，就是项目的setting，例如mysite.settings。然后self._wrapped = Settings(settings_module)。Settings应该是设置值的。 ---- Settings集成自BaseSettings，BaseSettings里只有一个__setattr__方法。看Settings的init方法，第一步导入global_settings，在同一个目录里，定义了全局的setting。导入使用dir获得所有变量名，判断变量名如果全为大写，就setattr。然后看BaseSettings，第一个判读"MEDIA_URL", "STATIC_URL"，必须以’/‘结尾。然后判断ALLOWED_INCLUDE_ROOTS必须是str，然后就设置。 然后使用import_module()导入项目settings，py3带的这个功能。。。 然后后边类似的判断导入项目settings，其中"INSTALLED_APPS", "TEMPLATE_DIRS"必须是tuple，不能是str不然设置成tuple。必须有SECRET_KEY，设置TIME_ZONE。ok了，导入变量完毕了。 ---- self._configure_logging() settings里的日志设置，先不看了，以后再说。

今天领导推荐这个项目，中午看了一下，核心就是一个函数一条命令。最后精简为 gdb -p 9252 -batch -eval-command='call PyGILState_Ensure()' -eval-command='call PyRun_SimpleString("exec(open(\"/home/a0x55aa/code/toto/hello.py\").read())")' -eval-command='call PyGILState_Release($1)' 如果提示“ptrace: 不允许的操作.”执行命令：echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope就好了。 用到gdb和python gil相关知识，不怎么懂，感觉就是与正在运行的进程争抢python虚拟机，执行完文件里的代码，over。 正好在grep ps命令的时候，看到执行python manager.py runserver 的进程有两个（为啥两个读源码里读到）。然后我查了一下ps命令的stat字段都是什么意思。 D 不能中断的进程（通常为IO） R 正在运行中的进程 S 已经中断的进程，通常情况下，系统中大部分进程都是这个状态 T 已经停止或者暂停的进程，如果我们正在运行一个命令，比如说sleep 10，如果我们按一下ctrl -z 让他暂停，那么我们用ps查看就会显示T这个状态 W 这个好像是说，从内核2.6xx 以后，表示为没有足够的内存页分配 X 已经死掉的进程（这个好像从来不会出现） Z 僵尸进程，杀不掉，打不死的垃圾进程，占系统一小点资源，不过没有关系。如果太多，就有问题了。一般不会出现。 下面一些是BSD风格的参数 < 高优先级进程 N 低优先级进程 L 在内存中被锁了内存分页 s 主进程 l 多线程进程 + 代表在前台运行的进程 以前也没用gdb调试过python程序，要学习一下。

urlconf = settings.ROOT_URLCONF urlresolvers.set_urlconf(urlconf) resolver = urlresolvers.RegexURLResolver(r'^/', urlconf) set_urlconf，如果没有设置urlconf的文件路径，保存；有，删掉。下边生成 resolver对象。 resolver_match = resolver.resolve(request.path_info) callback, callback_args, callback_kwargs = resolver_match request.resolver_match = resolver_match 找到RegexURLResolver里的resolve，match = self.regex.search(path)是匹配上边的 r'^/'，也就是path_info必须是’/‘开头，如果不匹配直接404。然后，生成新地址为去掉’/‘剩下的。获得url_patterns，从rulconf得到urlconf_module，从urlconf_module得到urlpatterns，就是url配置文件里的变量。然后返回urlpatterns。 然后遍历urlpatterns，这里要先看一下urls.py里的三个函数了，patterns, include, url。 def include(arg, namespace=None, app_name=None): 判断arg为tuple的写法是：include((urlconf_module, app_name, namespace))并且不能有namespace参数。这种写法没用过 不是tuple，判断arg的类型为string，导入urls.py.然后不是string就是mudule了。然后都获取urls.py里定义的urlpatterns。然后下边验证了一下每一个规则的类型。返回数据。返回的数据和参数一样，当arg为tuple时就是返回arg。 def url(regex, view, kwargs=None, name=None, prefix='') 先判断view为 list或者tuple就是有include的时候，返回RegexURLResolver对象。 否则view是string，返回RegexURLPattern对象。 def patterns(prefix, *args): 还是先判断是否可以为list和tuple，如果是，调用url()。说明在urls.py里url完全可以不写。如果是RegexURLPattern，添加前缀。最后返回所有的regex。也就是说最终的urlpatterns就是一个包含所有RegexURLPattern的list。 上边在dist-packages/django/core/urlresolvers.py里RegexURLPattern里的resolve，for循环urlpatterns，然后用每一个regex对象的resolve方法去匹配新的地址。当是include的时候 对象还是RegexURLResolver，所以还是这个resolve，起到递归循环。当是RegexURLPattern时，如果匹配成功，返回一个ResolverMatch，arg或kwargs是匹配的url参数，再在后边又更新上url()配置里的参数。如果匹配到最后还没匹配到，404。 ResolverMatch有一个ResolverMatch方法，用在这句上，callback, callback_args, callback_kwargs = resolver_match 并且将返回的ResolverMatch存到request里。 url匹配完了

WSGIHandler继承自BaseHandler，BaseHandler初始化的时候_request_middleware和其他moddleware变量都设置为None。 在WSGIHandler中，先通过判断_request_middleware为None，执行load_middleware。 在load_middleware里根据在settings.MIDDLEWARE_CLASSES里的配置导入所有middleware，并判断class里边包含的方法，分别插入相应的middleware列表里。现在_request_middleware是一个列表。load_middleware结束 回到WSGIHandler， set_script_prefix(base.get_script_name(environ))，get_script_name从environ得到SCRIPT_NAME，如果设置settings.FORCE_SCRIPT_NAME，回直接返回settings.FORCE_SCRIPT_NAME，默认为None。django竟然还提供这种碉堡的功能。。。set_script_prefix判断SCRIPT_NAME结尾是否是‘/’不是的话加上，并且在threading local里边保存SCRIPT_NAME。 signals.request_started.send(sender=self.__class__)，用来调用绑定到request_started的方法，大体看了一下没看懂。 request = self.request_class(environ)，得到request，初始化只是设置了一堆的变量。 response = self.get_response(request)，，在get_response里得到urlconf，settings.ROOT_URLCONF就是配置url的入口文件。这里先不看了，以后分析。接着在一个大的try语句里，设置response为None，遍历_request_middleware，只要有response返回就停止。如果执行完response还是none，下边匹配url找到view，然后遍历执行_view_middleware，有response就停止。然后遍历完response还是none执行view。 response = wrapped_callback(request, *callback_args, **callback_kwargs) 如果抛出异常，遍历执行_exception_middleware，返回response不为None就停止，如果最后为None，raise再抛异常。看出exception_middleware只用来在用户写的view里边出现异常的处理。 如果执行完view，还是none，就会抛出The view didn't return an HttpResponse object.的异常。 在这里前边的midddleware，只要有response返回，就不会执行后边的，直接到执行下边了。因为在执行middleware的前边，都先判断response是none才执行。 最后，判断response可调用render，遍历执行_template_response_middleware，最后调用response.render()。这个大的try语句检测执行上边这些操作的404 403等各种异常。 最后遍历执行_response_middleware里的方法，然后调用apply_response_fixes，执行response_fixes里的所有方法修改response。response_fixes在BaseHandler开始定义好了。处理完后返回response。 回到了WSGIHandler，设置http返回的headers，然后直接返回response。 WSGIHandler整个看完了，现在要详细看的好多了。 url的解析部分。 setting middleware里django的默认设置都做了什么。 wrapped_callback调view也看一下。（make_view_atomic这里是数据库事务相关内容） 还有没看懂的signal，以前也没接触过。

django在你执行python manage.py runserver的时候，在修改代码后会自动重启，研究一下是怎么实现的。 django/utils/autoreload.py main(),我只看python_reloader，RUN_MAIN通过搜索源代码，发现只有在这个文件有两处，一个是下边else执行时设置为true。也就是说开始可能没有设置值，先执行restart_with_reloader()。精彩到了。。设置新的environ，RUN_MAIN为True。用os.spawnve启动新的reloader()进程，现在RUN_MAIN为True！然后在restart_with_reloader这个父进程里一直在等待判断子进程是否返回exit code，如果不是3就退出循环结束了。 在的reload进程执行new_thread()，也就是启动一个server。下边执行reloader_thread() ---- reloader_thread()里边 先执行ensure_echo_on()，先判断termios是否导入成功，termios是一个py模块，是unix平台的控制通信端口的，不怎么懂。如果模块没导入成功，将不做任何操作。如果导入成功，从字面意思就是确保echo打开。这不懂，也不是重点。 下边判断RUN_RELOADER，开始为True，进入循环，判断code_changed()，如果只要有一个文件改变code_changed就返回true。然后接着sys.exit(3)。每隔一秒判断一次。 如果py文件改变，执行了sys.exit(3)，然后子进程就会结束。父进程在restart_with_reloader判断exit_code等于三，然后进行下一个while ture的循环。重新创建RUN_MAIN=True的子进程，重新创建一个server，等待（汗）代码修改 然后再退出，，，一直循环下去。 再说说exit_code不等与3的时候，比如子进程在启动server后，reloader_thread等待（再汗）代码改变的时候，你按了ctrl c，然后捕获KeyboardInterrupt异常，代码里什么都不做，然后子线程就会结束，这时exit_code不等于3，直接return exit_code结束了父进程，程序结束了。

这次从头看起。 --- 从项目的manage.py看，只有execute_from_command_line(sys.argv)这一个，sys.argv后边看到传不传一样。在django/core/management/__init__.py最后，ManagementUtility对象初始化，保存命令参数和项目路径。execute前边进行参数的解析，设置参数，最后一行 self.fetch_command(subcommand).run_from_argv(self.argv) 这个功能是执行相应的命令。 --- 先看fetch_command()，里边get_commands，取得django自带的命令和用户项目写的命令，返回map{命令：app_name}，django自带目录的是django/core/management/commands，app_name为django.core。还要过滤目录下的__init__.py。。。 下一步在fetch_command通过返回的字典获得app_name，下边就是根据app_name导入command。django通过判断app_name有没有BaseCommand来确定是否已经导入command模块（命令命名的py文件），如果没有导入，导入并返回里边的Command类就是定义的命令。最后返回Command类。 ---- 下边调用run_from_argv方法，这个Command类是集成BaseCommand，在django/core/management/__init__.py里边，先设置参数然后到execute里边。self.validate()model的定义检查等。然后执行了handler()就是命令的逻辑函数了。最后就是输出结果，有一个output_transaction，应该是操作数据库进行的操作，如查看数据表结构，后边看，看是数据库操作。 ---- 然后就是找到你想看的命令对应的文件看了。先看runserver了，其他先不看。 django/core/management/commands/runserver.py,handler()，先判断了DEBUG为false时，必须设置ALLOWED_HOSTS。然后ipv6的一坨，没看。 到了run（），只区分是否自动重载代码，不想自动加载要命令后边加上--noreload。然后只看自动重载的代码autoreload.main(self.inner_run, args, options)，不过也要用到self.inner_run。。。 ---- /django/utils/autoreload.py,main()，里边通过判断sys.platform开始字符串是‘java'选择使用哪个reloader。。没研究过jython，长知识。check_errors捕获执行inner_run时的异常。下边就是reload了，没看懂，等后边详细看看。 ---- 回到inner_run，开始打印了一堆提示信息。到get_handler里边返回get_internal_wsgi_application(). django/core/servers/basehttp.py,get_internal_wsgi_application,,判断settings里边是否设置WSGI_APPLICATION，默认设置，在项目里wsgi.py. 如果没设置，找get_wsgi_application，设置了导入wsgi.py,返回application，而application也是get_wsgi_application. get_wsgi_application返回WSGIHandler（）,/django/core/handlers/wsig.py，处理请求的逻辑在这里开始了。以后分析。 inner_run最后run(),WSGIServer继承自wsgiref.simple_server.WSGIServer。初始化传入，addr，wsgi_handler(刚刚返回的处理请求的逻辑！，后边用set_app设置)，ipv6的。 ----- 下边主要想看一下reload是怎么做的（纯属好奇）和WSGIHandle（最终目的！）

今天上午改了ror写的redmine的一个注册页面功能，主要验证用户名和邮箱地址前缀一样的功能，直接草代码。找到代码，写了一个验证函数，三个语法错误，启动的时候也没有提示，只能慢慢找但是不知道ruby语法半天找不出来，总共改了20行不到的代码。 然后ruby的交互模式进入命令是irb，我靠，不查都不知道。也不知道有没有命令查看安装软件都装了那些bin文件，只知道用dpkg可以看所有的。找到二进制文件就可以猜一下了。 群里推荐使用pry。用了一下挺不错可以使用终端的快捷键，写起来爽多了。irb直接进入交互模式是不支持的。 pry安装方法： gem install pry 然后pry启动 然后 我提示了Sorry, you can't use Pry without Readline or a compatible library.这个错误。 解决办法：sudo apt-get install libreadline-dev，sudo gem install rb-readline安装readline。 gem应该是一个类似python中pip的存在，可以使用gem list看都装的那些×和版本。