由于游戏客户端是flash+as写的，所以天天要在浏览器里用着测试。
一般来说，一两天崩溃一次是正常频率，这实在也未免有点太高了些。
老实说，其它动态语言就没怎么碰到过虚拟机崩溃的事情。
就算可能是浏览器的渲染层的问题，那也应该自己进行异常处理。况且在chrome里崩溃的时候，很明显是flash自己crash，渲染层还是正常的(不排除沙盒隔离了内外渲染层)。因此，很可能还是flash自己虚拟机运行as字节码时出的问题。
希望adobe在发展新功能的同时，认真解决崩溃问题，提高虚拟机性能，否则确如乔大爷所说，flash会很快成为昨日黄花。

从各方面的反馈来看redis的性能都在memcached等其它nosql工具之上，且提供了相当不错的功能，比买memcached支持的指令还多，所以必须出手分析一下了。

    自从linux 2.6.9后linux提供了驱动级的系统函数splice。它的作用是在文件描述符直接转发数据，直接对内核内存块做引用标记而不需要借用用户内存复制数据。这样就大大节省了分配内存，再read和write的性能消耗。
    自己用了一下这个函数发现总是返回EINVAL，于是去阅读HAProxy的源代码，总算弄明白了一些使用条件，理解了这个函数的设计思路。
    可以说splice本来就是用于select/poll/epoll等异步机制或者跨进程的通信，所以要求输入和输出必须至少有一个描述符是管道。于是我们可以看到以下清晰的流程：有数据读取时将来源fd的数据splice到pipe_in，然后异步请求写事件；写事件到来时从pipe_out再splice到目标fd。
    这样的流程处理常见的fd数据复制是够了，但是问题又来了，当处理网络socket描述符的时候，如果并发量很大，难道我们要为每个fd创建一对管道，那对系统是一个巨大的消耗。
    让我们看看HAProxy是怎么处理这个问题的：它用了一个pipe池，每当要做splice的时候就从里面取，不用的时候就放回去，而这个不用的时机很重要，也就是管道里的数据全部复制过去之后，这样管道只会在异步等待写出的短时间里被使用，同时的使用量就没有那么大，系统消耗就大大减小。
    以上就是一点点个人心得，希望对底层开发的程序员们有所帮助。

    写了这么多年代码，也看了这么多年别人的代码，越来越发现程序员是一个悲剧而矛盾的职业。
    至少在我写代码的时候就充满这样那样的矛盾，比如我喜欢追求运行效率，又喜欢比较优美的代码风格，却不喜欢写注释！
    而最令我苦恼的矛盾就是每个程序员会碰到但不一定会去思考的问题：自己实现，还是用现成库？
    对于懒人来说当然是直接现成的上，对天生自信喜欢一切掌握的人来说当然是自己实现。
    我在一个项目开始的时候也是倾向于自己实现的，毕竟我是个很懒的人。但项目进行到一半的时候我又往往喜欢直接抛弃第三方的库转而用自己写的，原因很简单：我对于不是自己写的东西抱有一定的戒惧之心，觉得万一出问题调试起来比较困难，自己不一定能迅速定位错误（所以我不用boost,ACE之类源代码比较绕的第三方库）。
    这大概就是多疑吧，当然也是对自己做的东西要求比较严格，做事情力求完成即完美的性格在作怪。
    暂时是没什么药可救了，期待自己能慢慢摆正开发心态咯。

感觉这玩意儿对编程思路转变要求极高，短时间还不能适应，从haskell到scala，尽管加入很多兼容特性，却仍不是我等习惯了过程式语言开发得人所能适应。

希望有时间可以系统研究一下这类语言，主要是因为其思路完全依照数学方法所以容易产生干净无二义性的代码这点我很喜欢。

参见http://gcc.gnu.org/gcc-4.6/changes.html :
GCC now supports Bionic C library and provides convenient way of building native libraries and applications for Android platform. Refer to documentation of-mandroid and-mbionic options for details on building native code for Android platform. At the moment, Android support is enabled only for ARM Linux target.

看解释是可以直接写应用，而不是ndk那样还需要用java调用，感动啊~~

其实原本该称之为C++1x了，可是大家鲜有改口的，我也就跟着大家叫吧。（都怪iso脑残迟迟讨论不出最终稿）

1. 大量tr1和boost中好用的类进入stl标准库，如unordered_map和bind，C++确实应该像python等语言学习，标准库里多放点基本类
2. 可变参的模板定义。这个改动终于在类似绑定的类定义的时候省下了大量的劳动力……
3. 内建的原子操作和线程类，跨平台程序员们肉牛满面……
4. lambda表达式，这玩意儿虽然破坏可读性，但懒人们纷纷表示影响不大，方便就好。
5. 列举型for，相当于php的foreach，实在是懒人们的福音啊。
6. extern模板实例，终于为编译时间做出了有益的改进……
7. 结构对齐关键字，跨平台er们再次肉牛满面……
8. 新的字符类型和内建unicode处理。东亚语言开发者们发来贺电……
9. 一些提高易用性和可读性的新特性，如类成员直接初始化和deleted关键字等。

由于受到其它开发速度快，学习成本低的语言的冲击，C++终于开始在新标准里大力推动易用性和跨平台兼容，个人希望这个标准能尽快定稿，并且各大编译器尽早支持。

好像没有打ehstatic补丁，不过已经属于可正常使用的范围。

下载见: http://code.google.com/p/qp-gcc/downloads/list