Firefox真是一個好東西，配上插件后異常強大，上圖便是我所使用的插件。
本命年真是難過。
本命年第一天，硬盤壞了。
今天早上，腳被車門夾了，晚上，肯定是今年最大的不幸了，和tt吵架了，吵很大很大。怪我太小心眼了吧，我是不怎么管事的人，天大的事情也與我無關，但在她的事情上，我格外“重視”。她說我有神經病，我承認。
以前問同事一個在日本待了幾年的同事，中國人在日本是不是受歧視？
同事告訴我，做人要不卑不亢，在哪里都不會受歧視。
是啊，做人要不卑不亢，為什么老覺得自己不如人呢？
挺起胸口做人，傲視人間笑紅塵。
信號量：
簡單點說，就是
1 一個整數變量i。
2 一個等待進程鏈表。
3 一對P/V操作函數。
P將i減1，如果i<0了，就把當前正在運行的進程加入到進程鏈表中，并阻塞之。
V將i加1，如果i>=0,則激活鏈表中的1個或者多個進程。
同時適用于單處理器和多處理器
自旋鎖：
在多處理器中，如果修改一些內核結構所需要的時間非常短（短于把進程插入進程鏈表中并掛起它所需要的時間），則應該使用自旋鎖。
80x86體系結構的兩種硬件約束：
1。ISA總線直接存儲器存?。―MA）只能對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，看起來能應付應付了，不過暫時還是不想把精力放到這個上面，今后再說吧，能測試就行了。不知道什么時候能找到朋友幫幫我啊。