Firefox真是一个好东西，配上插件后异常强大，上图便是我所使用的插件。
本命年真是难过。
本命年第一天，硬盘坏了。
今天早上，脚被车门夹了，晚上，肯定是今年最大的不幸了，和tt吵架了，吵很大很大。怪我太小心眼了吧，我是不怎么管事的人，天大的事情也与我无关，但在她的事情上，我格外“重视”。她说我有神经病，我承认。
以前问同事一个在日本待了几年的同事，中国人在日本是不是受歧视？
同事告诉我，做人要不卑不亢，在哪里都不会受歧视。
是啊，做人要不卑不亢，为什么老觉得自己不如人呢？
挺起胸口做人，傲视人间笑红尘。
信号量：
简单点说，就是
1 一个整数变量i。
2 一个等待进程链表。
3 一对P/V操作函数。
P将i减1，如果i<0了，就把当前正在运行的进程加入到进程链表中，并阻塞之。
V将i加1，如果i>=0,则激活链表中的1个或者多个进程。
同时适用于单处理器和多处理器
自旋锁：
在多处理器中，如果修改一些内核结构所需要的时间非常短（短于把进程插入进程链表中并挂起它所需要的时间），则应该使用自旋锁。
80x86体系结构的两种硬件约束：
1。ISA总线直接存储器存取（DMA）只能对RAM的前16MB寻址。
2。在大RAM的32位机中，由于线性地址空间太小的原因，CPU不能直接访问所有物理存储器。
所以，Linux把物理存储器分为三个管理区：
ZONE_DMA <= 16MB
16MB < ZONE_NORMAL < 896MB
ZONE_HIGHMEM > 896MB
在64位机中没有使用ZONE_HIGHNEN
摘要: 在Linux系统里，/usr/include/linux/if_pppox.h里面有这样一个结构：
1struct pppoe_tag {2 __u16 tag_type;3 __u16 tag_len;4 char&n...
阅读全文
Ghost Cheng “为了暖场”而提出的议题，引发了大家热烈讨论。
Hi all:
这两天maillist好像有点冷清了，我来立个靶子，大家讨论一下MMORPG的逻辑层构架。
所谓逻辑层构架，就是指MMORPG的跑地图、聊天转发、好友上线通知、交易事件等，
比如玩家或NPC跑地图的时候，以什么样的方式通知场景周围的玩家、转发聊天对话与好友上线通知的时候，如何才能尽量不去遍历玩家链表。
先说说我的想法，我处理的方式是基于EventEngine的，所谓EventEngine其实就是一个独立的线程，维护一个Event队列，
当对列中有事件的时候就处理。这里的事件包括：玩家动作（移动、攻击）、NPC动作（移动、攻击）、聊天、上线、下线等。
当数据包处理线程，收到玩家上线的数据包，就提交一个事件到队列，
同样，玩家发来攻击、聊天的数据后，也提交一个事件到队列。
NPC的事件触发时间，由另一个线程计算，一旦这个NPC到了需要移动或攻击的时候，就提交一个事件到队列。
这样确保所有的资源，都只有EventEngine一个线程访问，比如地图上的玩家链表等。
我遇到的问题：目前主要是聊天、或好友上线，这些事件处理的时候，需要遍历整个玩家链表，
这个链表就是网络层的session list，访问的时候需要锁定，如果有大量锁定遍历的操作，性能感觉会比较底，
不知道大家有什么好的方案？
希望大家踊跃发言哦！
http://groups.google.com/group/dev4server/browse_thread/thread/de6320c499f6dc3d/becf3963881399c8#becf3963881399c8
今天再次Review了代码，但思路却因此而开始混乱。
从名字上解这两个对象：
XmlPullParser当然是以“拉”的方式从流中获取信息。
SocketReader单从字面上理解，功能自然是从Socket上获取字节流。
“单一职责原则”，在几年前就在我脑子里打下了烙印。The Simpler The Easier，既是我做人的原则，也是我做程序的原则。常理上讲，我应该尽力维护这个原则，让上述两个对象都尽可能的简单。 在wildfire中，也有SocketReader，然而它的SocketReader却不是那么简单，功能远远超出了字面意义。大部分业务都要靠这个来控制，分配。
受它影响（之前我通读了wildfire的所有源码），在tim中也给SocketReader的子类ClientSocketReader等加上了重担。因为它掌握了太多的信息，应该说大多数信息都暴露在这个地方，Session，Socket，SocketConnection，我实在找不出理由不让它参与进业务。也许，这是OO的一种失败，但我一时也找不到新对象来管理这一系列的相关信息。
XmlPullParser则和SocketReader息息相关，因为Socket中Read出来的东西首先就要经过Parser，才能从字符流形成有用的东西。
在原先的设计中，XmlPullParser被SocketReader所包含，并提供了get方法暴露给外界。在很多事件分配的地方，都要XmlPullParser提供信息，之前，都是通过SocketReader间接获取xpp，高层真的需要直接使用xpp吗？我觉得不然，高层需要的信息完全可以通过SocketReader来提供。
那么该怎么设计两者的关系呢？是包含，还是父子？我倾向于包含，但懒惰促使我选择了父子。目前看起来，父子关系并没有带来什么坏的影响，如果有必要，今后再重构吧。
现在结构似乎更为清晰了，SocketReader的子类（ClientSocketReader。。。）会负责解析流，并根据解析出的内容进行第一层处理，如选择下级处理器或者是直接计算业务，或者是进行转发。。。根据不同的子类，表现不同的业务族（Client，Server，Agent。。。）
按照全局的事件分配机制，iq包被InputHandler所分配。
Iq包有两个小特点：
一是不需要像auth那样持续对话，服务端只收一次包就可以把一个iq业务处理完。
二是Iq包的接收和应答是无序的，靠id对应起来。
那么iq的处理机制，该怎么设计呢？
2006.03.05
今天晚上Parser崩溃了，这个临时性的东西真不好伺候阿。
2006.03.06
重新写了一个“临时”的新PullParser，看起来能应付应付了，不过暂时还是不想把精力放到这个上面，今后再说吧，能测试就行了。不知道什么时候能找到朋友帮帮我啊。