asung811的专栏

debug com对象的release计数

asung811 — Thu, 02 Jun 2011 19:14:00 +0800

以前没有接触过com编程，这段时间的项目用到了dshow，在调试的时候发现程序长时间运行的时候，句柄和线程数一直在不断的上涨。猜测是com对象没有释放导致的。
调试的时候可以跟到release函数，看汇编可以猜出来哪个地方是判断reference计数的。如果不正确，就仔细检查它的使用。我犯得错误是在createInstance里面new了一个新对象，然后又addref了，实际上createInstance的调用者会addref，在里面就没有必要了。还有使用filter graph的时候，最好在最后把filter都delete，然后再graph->release()；以后不会用到的interface，一定要即使的release，别等到最后清理的时候来弄。

调用CoFreeUnusedLibraries可以把没用的库从进程中卸掉，但是有个时差：10分钟，这是为了保证多线程的安全，但是在单线程中表现也是一样的。CoUninitialize也有10分钟的时延。

django 1.3使用static file

asung811 — Sun, 29 May 2011 23:23:00 +0800

django1.3 中使用satic files的步骤

db svr 终于完工

asung811 — Wed, 14 Jul 2010 17:06:00 +0800

这几天终于把db svr侧的程序完全调通了。一开始测试长时间的流量，总有问题，仔细分析日志发现是mysql在执行load的时候没有关闭FIFO，导致程序下一次打开的时候（两次间隔非常短）返回成功，以为是新的load命令载入，是加上还是上一次的。等到mysql做完load关闭FIFO的时候，程序再往里面写的话就出现的errno为EPIPE的错误。解决的方法是利用两个sem来做同步。之后长时间的测试一直没有问题。现在还得帮助leader调试reader，也是问题一大堆。只是老大很浮躁，呵呵。也是，他老人家事情太多，不像我可以专心编代码。做一个产品真不容易，方方面面都得考虑到。这几天对silverlight非常感兴趣，打算晚上去试一把。还是要多新产品充满好奇才行，特别是IT这个充满了变数的行业。

UT

asung811 — Tue, 29 Jun 2010 23:23:00 +0800

经过两个星期的奋战，代码初步完成雏形。中间由多进程改用多线程，采用同步信号处理方式，loader按需调用的方式花费了大量了精力，对了，还有FIFO的打开和关闭。最终的程序只有一个进程，主进程根据数据库的配置，起若干个station线程，然后监听网络；station线程初始化两个loader实例。当有服务请求时，主进程起service线程响应，service线程根据数据包的属性将其分发到不同的station线程上面，此时适当的loader实例会再起一个线程负责query以及和station线程进行交互。现在的模型基本实现了原来的设想：loader按需启动，定时关闭FIFO以节约资源，能处理time exception等等。中间大量使用了线程库，包括condition，mutex，sem。也碰到了很多的问题，比如说传入线程主函数的参数被覆盖、定时器响应函数和主流程冲突、FIFO的处理等等。总的来说，学到了很多东西，也温习了很多的东西。但是也有不足的地方，比如说不支持多实例（主要是因为目前的FIFO不能区分开，比较好弄）、线程之间耦合太紧、抽象不够等等。对于耦合的问题，我

多线程环境下的信号处理

asung811 — Thu, 24 Jun 2010 23:23:00 +0800

今日开发摘要

澄清需求真是很痛苦的事情

asung811 — Thu, 24 Jun 2010 11:19:00 +0800

特别是你的“客户”也不知道自己的需求是什么的时候！所以有了敏捷开发，唉，关键是老大允不允许在这个关键特性上来个敏捷呢？

这几天用多线程

asung811 — Mon, 21 Jun 2010 23:55:00 +0800

系统正式开发有大半个月了，由于有非常多的loader需要同时运行，所以选择多线程来实现。伺服进程M首先创建若干个S进程；如果有服务请求到达，M创建服务线程E。E和S之间用FIFO用以传递数据。当有数据到达之后，E通过FIFO传给S，S启动一个线程Loader（Loader和S之间也是FIFO）。由于Mysql的loader命令如果成功执行的话是一直阻塞的，只有出错的时候才立即返回，所以S主线程和loader线程很不好同步。所以我已开始使用block模式操作S与loader之间的FIFO出现了问题。当loader应为mysql的表没有创建好的时候立即出错返回，之后S才以默认block的方式打开FIFO，导致S一直阻塞在open操作上；S一阻塞，导致同样是以默认方式打开FIFO的E线程也被阻塞；E一阻塞，服务器端没有人去服务socket，导致客户端也被阻塞在send上面。唉，真是惨啦！当初我也是意识到阻塞模式读可能会有问题，所以特别小心的处理各个线程的启动问题，没有想到还是阴沟里面翻船了。不喜欢非阻塞模式是因为不喜欢去一遍遍的处理EAGAIN错误。尝试了一种解决方案：1. 以O_

像老外学习

asung811 — Mon, 24 May 2010 22:58:00 +0800

平时和老外打交道比较多，对老外的印象一直不错，但是对某些同事和老外交往的时候的一些方式不是很认同，觉得有些奉承。其实老外看重的还是实力，并且他们的实力确实很厉害。前两天在弄oracle和IB的性能测试，我写的脚本比较简单，并且没有加入统计的功能，各组query的时间还得自己取几个样本，当时嫌麻烦没有写脚本自动生成。今天看到了老外在IB上测试脚本输出：真是漂亮！各种query的情况一一列出来，测试结果一目了然。让我佩服！做事的态度让我很是汗颜！

有道难题

asung811 — Sat, 15 May 2010 00:51:00 +0800

网易的有道难题比赛又开始了，今天刚从家里回来，闲来没事，刚好可以看看这写东西唤醒一下记忆。看的是09年的题目，第一道题比较简单，第二题和第三题的话就有些难度。前两道题比较有代表性吧，可以先实验几个例子，从中找出规律和特例即可。第三道题我想了一会儿，没有头绪，第一是觉得概率算得似乎不对；第二是未知量太多，觉得无从下手。稍微看了下后面的解释，有点豁然开朗的感觉。关键是思路，这个可以作为动态规划的典型了。今天脑子不够用，明天再仔细研究下。有道的那些谜语不知所云，自己太笨了，还是答案过于刁钻？

我们正进入另一个黑暗和无知的时代----《三联生活周刊》 (转载)

asung811 — Sun, 02 May 2010 17:41:00 +0800

美国埃默里大学的英语教授马克·鲍尔莱因写了《最愚蠢的一代》，就得罪了8700万美国年轻人。在书中，他提出一个让美国教育界困惑不已的问题：在整个人类历史上，知识从来没有像现在这样普及过：图书馆、博物馆、大学、历史频道、维基百科、《华尔街日报》、《纽约时报》，一切都在你的鼠标下，但我们没有看到年轻人，至少是美国年轻人，包括高中生和大学生，在历史知识、公民意识、阅读成绩、国际竞争力方面的提高。为什么？ “因为他们把时间都花在了社交网站、IM（即时通讯软件）和手机短信上了。”在接受本刊记者采访时，鲍尔莱因说。马克·鲍尔莱因（Mark Bauerlein）对Facebook尤其深恶痛绝。尼尔森的调查数据显示，年轻人最常去的10个网站中，9个是社交网站，“一个人成熟的标志之一就是，明白每天发生在自己身上的99%的事情对于别人而言根本毫无意义”。但是，将这样的罪名完全归结到数字技术身上，是否过于粗暴和简单化呢？ “其实，我的想法很简单，年轻人需要在自己的生命中保留一个空间，可以与历史、与艺术、与公民理念相遇。”鲍尔莱因说，“如果他们 24小时腻在一起，这点要求也变得