月度归档：2013年02月

Bash之命令历史的存储和记录

发表回复

在Bash中我们可以使用 history 命令回顾，修改和重用之前使用过的历史命令。去掉信号机制、去掉作业控制、去掉各种参数调用，今天我们只看下Bash中如何记录命令，如何存储历史命令。

在 Bash 的源代码中，history 命令的定义代码为 builtins/history.def ， builtins 目录下存放的是内部命令的源代码，每个内部命令是一个def文件，如history.def，cd.def等。 Makefile中DEFSRC声明了所有内部命令的def文件。由 mkbuiltins.c 生成编译时辅助工具 mkbuiltins，mkbuiltins 处理 *.def 文件，生成命令的 *.c 源程序以及 builtins.c 、 builtext.h。 builtins.c 和 builtext.h 相当于各个内部命令的索引。

history.def 的作用是解析命令并将不同的参数分发命令到不同的功能实现，如读取命令、覆盖命令等。一些功能实现代码文件在 bashhist.c/bashhist.h，但是关于历史记录的基础操作并不在这两个文件中，它们在 lib/readline 中。这是因为 Bash 采用的GNU Readline函数库中。 Readline提供了统一的行编辑和历史记录功能的命令行交互方式。

history命令在显示时会显示所有的历史记录，这里的所有历史记录包括最开始从文件中读取的历史记录，还包括当前会话产生的记录。假设你的历史记录中已经有了500条命令，如果你用其它文档编辑器将历史日志文件写到1000条，打开终端，你会发现显示的还只有500记录。这是因为在打开终端初始化时，不仅仅有历史记录列表的读操作，还会有关于文件记录数限制的初始化操作，确保文件中的记录条数不会大于设定的最大值。这个初始化操作在 load_history 函数中实现，函数最开始就做了两次历史记录文件的截取操作，一次是默认500，一次是设置的最大值： HISTFILESIZE 。

在历史记录中有一个会话的概念，不同会话中的命令在没有保存到文件前是不会互相冲突的。比如，打开终端A如果你删除 .bash_history 的前10行命令，保存，在命令行中输入history，你会发现输出的命令历史记录并不是从1开始，而是从11开始的。如果此时，你再开一个终端B，输入若干条命令后，再输入history，你会发现历史记录中没有在终端A输入的命令。这是由于在一个终端会话中，历史记录从固化存储位置的读取操作只有一次，写入操作也只有一次，即在打开终端时读取，在关闭终端时写入。

除了文件存储，历史记录也可以记录在MMAP，对应的宏定义为 HISTORY_USE_MMAP。

如果以文件存储方式，命令记录以一行一条命令的方式存储在.bash_history（默认，如果有设置 HISTFILE 则优先使用 HISTFILE 中的值），虽然我们使用 history 命令时看到每条命令前都会有一个标号，我们可以使用　!标号　的方式重新执行命令，这个标号并不是唯一不变的，标号是在初始化时在读取文件时在程序操作中标记的，后续有命令加入时，标号会自增，这个自增并不会受历史记录的最大值限制。

当一次会话退出时保存历史记录文件，将历史数据固化存储，并将会话统计清零。当存储到文件时，Bash 会将此前会话中的命令直接存储到文件末尾，如果文件的记录数大于定义的最大记录数，则清空旧的历史命令，并且当下次再存储时会重写此前文件。代码示例如下：

      if (history_lines_this_session <= where_history () || force_append_history)
        append_history (history_lines_this_session, hf);
      else
        write_history (hf);
 
      sv_histsize ("HISTFILESIZE");

存储操作最终还是归集于存储介质的读写操作，如对文件的读写，增加的只是对业务逻辑规则的各种限制。命令可以在执行命令时记录，也可以在命令刚输入，但已经识别的情况下记录，Bash 属于后者。 Bash 在 yacc 做语法分析时将用户输入的命令通过 maybe_add_history 函数写入到当前会话的命令历史记录表中。在做语法分析时就已经记录了用户输入的命令，此时记录就不用管命令最终的结果是怎样，也不用管如果执行过程出了异常会怎样处理。它只是如实的在执行前记录用户输入的什么命令，由此，我们可以定义 Bash 的命令历史记录的定义为用户输入的命令历史记录。

参考资料： http://files.linjian.org/articles/techreport/bash_study.tar.gz

Yii 框架的视图层实现

2条回复

如果你想看看 Yii 框架的视图实现过程，请继续向下；如果你想看看胖子的碎碎念，请直接拉到文章最后；如果你只是路过，那也路过留名吧^_^。

Martin Flower 在《企业应用架构模式》中提到 MVC 模式的关键点在于两个分离：从模型中分离视图和从视图中分离控制器。视图的表现在很大程度上决定了此模式的使用，以及框架对 MVC 模式的各个层级的分离水平。 Yii 框架是一个基于 MVC 模式的框架，它在视图这块做了很多的工作，很清晰的实现了视图的功能。

Yii 框架的视图是一个包含了主要的用户交互元素的 PHP 脚本。每个视图有一个名字，当渲染( render )时，名字会被用于识别视图脚本文件。视图的名称与其视图脚本名称是一样的。例如:视图 edit 的名称出自一个名为 edit.php 的脚本文件。要渲染时，需通过传递视图的名称调用 CController::render()。这个方法将在 “protected/views/控制器 ID” 目录下寻找对应的视图文件，其寻找方法为 getViewFile。这里的 protected/views 只是默认的存储位置，我们可以通过 Yii::app()->setViewPath 方法改变此路径。

在视图脚本内部,我们可以通过 $this 来访问控制器实例。同时，我们也可以在视图里以“$this->属性名”的方式获取控制器的任何属性，这种调用方式是通过实现__get魔法方法实现的。

一次较为完整的视图渲染过程在 CController 类的 render 函数中体现得淋漓尽致。当控制器中从模型（model）中拿到数据后，一般会执行 render() 方法创建视图，其大概过程如下：

  1. 执行预留的 beforeRender 钩子。
  2. 查找渲染局部内容 $output，实际上这里是一个部分视图渲染的过程，它包括获取视图文件路径，渲染视图文件，处理输出三个部分。在渲染的过程中，通过 PHP 中的 extract() 方法把数组中将变量导入到当前的符号表，直接 require 视图文件，从而合并数据和表现。
  3. 如果存在布局，则将得到的内容放入以 content 为下标的的数组传递给父类的 renderFile() 方法中，重复执行渲染视图的过程。在布局中执行 ，输出局部内容$output，实现了局部和布局视图的合并。为了实现多级布局，在布局中还可以通过控制器的视图装饰方法加载。
  4. 执行预留的 afterRender 钩子。

在渲染视图的时候，如果参数中有传递对应的值，会执行 processOutput() 方法，此方法一般在渲染视图结束时才会调用，它实现了三个过程：

  1. 注册客户端脚本，具体由 ClientScript 组件管理。
  2. 如果存在，则执行动态内容输出。
  3. 页面内容 base64_encode 加密，如果存在 zlib 扩展，则会先压缩。

在 CController 类中对视图的渲染除了上面的render方法外，还有其它多种方法：

  • render方法： 和布局一起渲染 render($view,$data=null,$return=false)
  • renderPartial方法： 仅渲染视图内容，或者是渲染部分页面内容。它与 render() 方法的不同是它不会渲染布局，并且在 render() 方法中也会调用此方法。 renderPartial($view,$data=null,$return=false,$processOutput=false)
  • renderText方法：渲染静态内容和布局。renderText($text,$return=false)
  • renderDynamic方法：通过回调函数渲染动态内容，通常我们会在模板文件中中调用此方法。renderDynamic($callback)->renderDynamicInternal($callback,$params)
  • renderClip方法：渲染显示 CClipWidget 生成的内容，此处需要指定名字。renderClip($name,$params=array(),$return=false)

对于不同的页面中共用的内容，虽然可以通过 renderPartial 方法渲染部分页面视图，但是必然存在对于数据部分的重复，因为这些视图都需要调用控制提供的数据，从而产生耦合。因此 Yii 框架 提供了另一个独立的视图部件，官方称之为 Widget （小物件？小挂件？）。

小物件是 CWidget 或其子类的实例。它是一个主要用于表现数据的组件。小物件通常内嵌于一个视图来产生一些复杂而独立的用户界面。也算是一种界面的独立和松耦合的设计。如我们做WEB应用时常用的列表，翻页，日历等。这些 Widget 增加了界面的复用度，减少了代码量。

与前面视图部分不同的是，它没有布局文件支持，并且 Widget 视图中的 $this 指向 Widget 实例而不是控制器实例，这里实现了与控制器的分离。如果要实现一个自定义的 Widget ，我们仅需要继承 CWidget 并覆盖其 init() 和 run() 方法,可以定义一个新的 Widget 。

我们在视图中通过 $this->widget（） 或 $this->beginWidget() 和 $this->endWidget() 调用 Widget，两者的区别在于第二个方法可以在显示的过程中添加 html 内容。添加内容的位置在 init() 方法和 run() 方法输出的内容之间。

除了布局、Widget 外， Yii 框架实现系统级的视图，用来显示 Yii 的错误和日志信息。

系统视图的命名遵从了一些规则。比如像“errorXXX”这样的名称就是用于渲染展示错误号 XXX 的 CHttpException 的视图。在 framework/views 下, Yii 提供了一系列默认的系统视图. 我们可以通过在 protected/views/system 下创建同名视图文件进行自定义。系统默认的 exception 视图非常赞，结合 Yii 本身的 traces 机制，当抛出异常或出错时就会很详细的定位出问题的代码所在。

以上只是胖子阅读 Yii 框架源码的笔记。结合《企业应用架构模式》这本书的内容，如页面控制器、前端控制器、活动记录等，胖子发现对框架的实现有更深入的理解。一方面印证了书上的理论，一方面为实现过程的原理找到了出处。不晓得 Yii 框架的作者是否对此书也有精读，或者是经验的积累？

参考资料： http://www.yiiframework.com/doc/guide/1.1/en/basics.view

PHP的ticks机制

1条回复

PHP的ticks机制

要过年了，在年前完成这篇文章，如果有缘可以看到，祝福看到的朋友新年快乐，在新的一年里，万事顺意！

按今年的计划每个月至少有两篇文章，而一月份因为各种理由而只有一篇2012的总结，无论什么原因，总归是不对的。这篇算是补上的，也作为今年的开始。

回正题，今天要研究的是PHP的ticks机制。

PHP提供declare关键字和ticks关键字来声明ticks机制。如：declare(ticks = N); 这表示：在当前scope内，每执行N句internal statements（opcodes），就会中断当前的业务语句，去执行通过register_tick_function注册的函数（如果存在的话），然后再继续之前的代码。需要注意的是这里的N是指的PHP的一些OPCODE，而OPCODE与我们见到的PHP语句却不是一一对应的。

最开始我以为PHP内核是在编译时记录是否有ticks机制，在真正执行中间代码时插入判断代码，实现此机制。但是事实上却不是这样滴。

看PHP代码示例1：

    $name = "phppan";
    echo $name;
    class Tipi {
        public function test() {
            echo "test";
        }
    }
    function f_tipi() {
    }

如上代码包括了我们常见的几种语句，赋值，输出，定义类，定义函数。通常我们用VLD查看PHP生成的中间代码，上面的代码通过 php -dvld.active=1 t.php 我们会看到 ECHO、ASSIGN、NOP等中间代码。

现在我们在示例1的代码上添加上ticks机制。如PHP代码示例2：

    declare(ticks=1);
    $name = "phppan";
    echo $name;
    class Tipi {
        public function test() {
            echo "test";
        }
    }
    function f_tipi() {
    }

示例2与示例1相比也就是多了第一条语句： declare(ticks=1); 如果我们此时再次通过VLD查看中间代码，会发现在每个中间代码的后面都多了一句中间代码：TICKS 。

是否因为ticks=1的原因而在每个中间代码的后面添加了TICKS？将declare(ticks=1);换成declare(ticks=100);，再次VLD，结果没有变化。从以上的结果可以看出，PHP内核在语法分析过程中实现了ticks机制。

从实现过程来说定义ticks机制分为两个过程：一个是定义是否需要执行ticks或者说声明ticks机制，另一个实现在声明了ticks机制的情况下控制语句的执行。

声明ticks机制过程

声明的过程就是调用declare(ticks = N); 在语法分析时根据declare关键字和参数中的ticks关键字来声明ticks机制。通过zend_compile.c文件中的zend_do_declare_begin、declare_statement、zend_do_declare_end三个函数来编译声明ticks机制。在declare_statement函数中我们可以看到：declare除了可以声明ticks之外，还可以声明encoding，这在代码里面就是一个if else的判断。

ticks机制的声明仅在编译过程有用，它为后面的声明控制语句服务。其编译过程中的全局变量为：CG(declarables)。这是一个结构体，它仅有一个成员：ticks。当然后面应该还会有更多的成员出现。

声明控制语句

示例1和示例2已经充分说明在每条语句的语法分析时，会根据是否声明了ticks机制来添加TICKS中间代码，其实现在于每条语句在语法解析时都会添加一条函数调用：zend_do_ticks。从zend_language_parser.y文件中可以看出：zend_do_ticks函数添加在类定义语句，函数定义语句和常规语句的后面。 zend_compile.c文件中的zend_do_ticks函数会根据前面提到的 CG(declarables).ticks 来判断是否生成 ZEND_TICKS 中间代码（在VLD中看到的中间代码都是没有ZEND开头）。

除了声明ticks机制，还有执行。执行过程中关键的变量是在声明时的ticks=N。其实这里的N可以换个角度去理解：ticks指定的数字是指执行了多少次TICKS语句。在TICKS中间代码的执行函数ZEND_TICKS_SPEC_CONST_HANDLER中，会统计执行当前函数的次数，存储变量为EG(ticks_count)。当达到当初声明的界限，就会调用一次所有通过register_tick_function注册的函数，并计数清零。

与当初自己设想的实现相比，PHP内核对ticks机制的实现满足了功能单一原则和松耦合原则。将ticks机制作为一个中间代码添加到整个中间代码的执行体系中，包括状态的转移，函数的切换这些都是直接使用原有的机制。

ticks机制的应用场景

手册上说：Ticks 很适合用来做调试，以及实现简单的多任务，后台 I/O 和很多其它任务。

在调试过程中，对于定位一段特定代码中速度慢的语句比较有用，我们可以每执行两条低级语句就记录一次时间。虽然这个过程也可以用其它方法完成，但用 tick 更方便也更容易实现。

PCNTL也使用ticks机制来作为信号处理机制（signal handle callback mechanism），可以最小程度地降低处理异步事件时的负载。这里的关键在于PCNTL扩展的模块初始化函数（PHP_MINIT_FUNCTION(pcntl)）。在此模块做模块初始化时，它会调用： php_add_tick_function(pcntl_signal_dispatch);将pcntl的分发执行函数添加到ticks机制的调用函数中去，从而当ticks触发时就会调用PCNTL扩展函数中指定的所有方法。