对于poe cookbook中Tk interface一例的解析

起因

Perl-Tk 在windows下的表现着实让我头疼了很长一段时间，最无法忍受的一点是缺乏稳定的线程支持。比如，无法在一个界面上一边录制新闻，一边完成下一个录制时间的设定，整个程序被阻塞在那儿无法动弹。某些情况下可以使用非阻塞的本地socket来实现进程间的通信，但这么做很费劲，而且使得程序像一个奇怪的网络服务器。POE作为在单进程中实现并行的框架，提供了对Tk的支持，很好地解决了组件间通信的问题。

大致的介绍

# !/usr/bin/perl

use  warnings;
use  strict;

use  Tk;
use  POE;

POE :: Session -> create(
    inline_states  =>  {
        _start  =>   \& ui_start ,
        ev_count  =>   \& ui_count ,
        ev_clear  =>   \& ui_clear ,
    }
);

$poe_kernel -> run();
exit   0 ;

sub  ui_start {
     my  (  $kernel ,   $session ,   $heap  )  =   @_ [ KERNEL ,  SESSION ,  HEAP ];
    
     $poe_main_window -> Label(  - text  =>   " Counter "  ) -> pack ;
     $poe_main_window -> Label(  - textvariable  =>   \ $heap -> {count} ) -> pack ;
    
     $poe_main_window -> Button(
         - text  =>   " Clear " ,
         - command  =>   $session -> postback( " ev_clear " ) ,
    ) -> pack ;
    
     $kernel -> yield( " ev_count " );
}

sub  ui_count {
     $_ [HEAP] -> {count} ++ ;
         $_ [KERNEL] -> delay(  " ev_count "   =>   . 5 );

     #  $_[KERNEL]->yield("ev_count");
}

sub  ui_clear {
     $_ [HEAP] -> {count}  =   0 ;
}

很容易可以看出来一个不一样的地方，比如说用$poe_kernel代替了一贯的POE::Kernel，但在实际运行中会发现$poe_kernel是对POE:;Kernel的引用，最终起作用的依然是POE::Kernel。好了，除了这一点外，其他还是与传统的POE程序差不多。

首先建立了一个包含了内置_start和两个自定义（ev_count，ev_clear）事件的session。之后在_start事件中，在已初始化了的$poe_main_window上建立一个内容为“Counter”的标签，内容为变量$_[HEAP]->{count}的标签和一个用来清零的按钮。至于ev_count和ev_clear事件不过是自增和清零$_[HEAP]->{count}而已，其中ev_count事件会递归回调自身以实现不断自增的过程。

如果一切顺利，运行之后的结果如下图所示：

 

单击Clear按钮，中间的数字将从零开始继续飞速自增。如果想让它自增得慢一点，或者说可以看得清，可以在ev_count事件中delay自身回调一小段时间。需要注意的一点是不要指望用sleep，因为它会让整个POE崩溃。

一些细节

下面来讲一下隐藏在这一切背后的一些小细节。事实上，这些细节危险重重，任何细小的错误哪怕是位置的改变都可能导致程序的失败，而原文中的某些注释也比较晦涩或者是存在误导，需要详细说明一下。

$poe_main_window 在strict环境中出现，这让我很吃惊。一般情况下，这样的非my变量是无法通过检测的。唯一的解释是use POE在背后干了很多事情，多得连POE::Kernel都增加了叫一个$poe_kernel的引用，当然这是为了保证POE::Kernel不被自动垃圾回收。在这里不得不说的是，use Tk必须出现在use POE之前，否则use POE不会初始化生成$poe_main_window。所以可以这么认为，use POE会通过检测其之前的模块调用来决定之后的框架行为，这点在其他模块的应用中不是很多见，至少在我是第一次看见。

原文中有这么一句话“Widgets we need to work with later, such as the counter display,must be stored somewhere.The heap is a convenient place for them.”意思是说“要在之后用到的组件，比如说显示自增计数的标签，必须存储在某个地方，而堆栈就是一个方便的场所。”这也让我感到很困惑，至少在这个例子中，之后没有显式地用到这个计数显示标签。如果非要说用到，那么就是ev_count事件中的$_[HEAP]->{counter}以textvariable的身份影响到其宿主，但事实上这非常隐晦，而且为此保存一个引用似乎也毫无意义。后来的实验证明了我的猜测，在注释掉这个引用之后程序依然可以正常运行，也就是说原文这句话并非针对于本例子或者说毫不相干，其中的“such as”极易引人误入歧途。它真正想说的是，为了可以在某个事件中改变组件的行为，需要一个全局可见的引用，而$_[HEAP]正是恰当的选择，其实用一个全局哈希表就可以得到相同的效果，只是这么多就显得多余了。

最后的一点是有关于POE本身的机制。在ev_count中为了实现不断自增，在其事件处理句柄中有一句自身回调，而在ev_clear中仅仅是将计数清零了而已。一开始我有些担心自增行为会中断，因此在ev_clear中增加了一句触发ev_count事件的命令，但这么做是多余的。首先POE中的每一个事件句柄都是并行的，因此ev_clear不会中断ev_count的行为；第二，作为两个事件之间关联的全局变量$_[HEAP]->{counter},POE为其提供了锁保护，不必担心其中一个事件的行为导致另外一个崩溃。

几句话

因为不是正儿八经地写论文，所以遣词造句就显得随性了一些。倒不是说我可以不认真了，相反地，对于一些细节倒是表现得更自然。

这个例子非常简单，简单得几乎没有实用价值，但是说明了问题。我认为一个好的tutorial就应该这样，简单而能说明问题。简单就是说容易让人看懂，说明问题则是把注意事项讲清楚了，之后全凭各人兴趣和悟性了。POE Cookbook是一本非官方的技术文集，没有出版物，甚至说如果你写了一个好的例子，也可以被收录其中。但是每个例子都很通俗易懂，从最简单的入手，由浅入深，最后形成一个系统。反观国内的一些技术出版物，往往枯燥理论先讲一大堆，吓跑一批人；再举一两个可以堪称作者代表作的复杂例子，又闷掉一批人，结果是弄得是曲高和寡。