學習時間的過程終會有反覆，其中也包括一些錯誤，上午對於前一篇關於epoll的文章進行了增改，下午就覺得有些不妥，重新編輯感覺不太容易剝樓錯誤，現在有些新的變化在這裡重新論述。
上午說的在epoll裡面進行耗時任務的時候做乙個任務排程器（比如當伺服器連線外部資源），這說明我只了解了epoll的一部份，沒有充分認識到它的普 遍意義的應用，其實對於外部連線epoll可以作為伺服器端的任務排程器使用，但是它同樣適用於主動式連線的socket，換言之，如果伺服器需要連線外 部socket資源也同樣可以將它連線的道德socket fd加入epoll的監視，這樣epoll的排程就更有廣泛了，所有需要socklet互動的部分都可以交由epoll，然後他負責監製epollin和 epollout兩個事件，這兩個事件的組合多次利用就可以構成整個服務事件驅動機制，所以我上午說的任務排程其也是多餘的。
有人可能想了，那麼對於多核伺服器不久沒有任何優勢了麼？我的設想是這樣的，先在單執行緒的模型上完成開發，如果想擴充套件到多核，可以在epoll的下面再次 構建乙個多執行緒的任務排程器，也就是將epoll檢測到的事件再次儲存到乙個結構體，用多執行緒去讀取並處理事件，這樣不會影響大部分的**，真正的程式不 是直接響應epoll事件，而是在新的任務排程器下面統一處理epoll事件的副本，這樣就有epoll主動事件驅動呼叫變成了非同步的，多執行緒並行執行的 模型，但是每個連線同一時間也只有乙個執行緒在處理，現在還沒有經過實際測試，不確信對於效能的影響如何。
如果所有實際的處理過程暫用cpu很短那麼加上我上面設計的一層任務排程就是多餘的，因為所以的問題都會集中體現在網路上，這不是伺服器所能解決的，如果 網路快到了事件在等待任務，那麼這種模型才有可能有較好的表現，所以是否應用還是要看具體的服務內容，事實證明單執行緒已經處理的足夠快了，每秒1萬頁的處 理速度能滿足絕大多數的需求，所以就設計而言，關鍵問題還是要解決瓶頸，而不是將所有想到的好技術都應用上，瓶頸可能還沒有得到解決，反而更加浪費cpu 資源。
所以我覺決定還是全部以epoll驅動去做這個web架構，畢竟nginx等都有上佳的表現，這樣看來做個**或者反項**也是很容易的，還可以更加節約資源
看了這麼久才算對於nginx等處理模型有了個大致的了解，起初打算更改它的**，後來發現太麻煩了，所以重新自己架構，走下來發現只要了解思路了具體的技術是很快的，不然看別人的**太辛苦了
再論php開發環境 原創
事過境遷，zendstudio 8 都出來好久了，但是對於zendstudio 8 的單步除錯一直不好使。今天調通了，現在來總結總結。zend 公司提供了 多種debug 方式 個人認為 從前提供 tool bar studio zend plateform studio zend server s...
再論雙分派
暴力雙分派速度快，可是當類增多時，代價依然很大。map雙分派在速度優化上有dynamic cast和static cast兩種選擇，loki把這個選擇做成了policy。矩陣雙分派速度上有天然的優勢，但是你要修改你的類。於是loki也把這個做成了policy供你選擇。矩陣雙分派的思想是，在你的cla...
再論向上轉型
向上轉型的好處，已經在這篇文章 這是乙個鏈結 的 中演示了，但是沒有說不好處。現在就說說不好處，以鏈結中的 為背景，animal a1 new lion animal a2 new mokeny new出來的lion和mokey物件向上轉型為animal物件，可以使用統一的eat 讓jvm去分辨到底...