**：風吹過夏天的chinaunix部落格
首先看程式一，這個程式想要實現的功能是當使用者從控制台有任何輸入操作時，輸出」hello world！」。
l 程式一
#include
#include
#include
using namespace std;
int main(void)}}
執行結果：
程式一中對標準輸入的監聽使用et模式，結果實現了我們想要的功能。那麼實際原理是如何呢，我們將過程分析一下：
(1) 當使用者輸入一組字元，這組字元被送入buffer，字元停留在buffer中，又因為buffer由空變為不空，所以et返回讀就緒，輸出」hello world！」。
(2) 之後程式再次執行epoll_wait，此時雖然buffer中有內容可讀，但是根據我們上節的分析，et並不返回就緒，導致epoll_wait阻塞。（底層原因是et下就緒fd的epitem只被放入rdlist一次）。
(3) 使用者再次輸入一組字元，導致buffer中的內容增多，根據我們上節的分析這將導致fd狀態的改變，是對應的epitem再次加入rdlist，從而使epoll_wait返回讀就緒，再次輸出「hello world！」。
我們在看看lt的情況如何，將程式一以下修改：
ev.events=epollin;//預設使用lt模式
執行結果：
結果正如我們所料，程式出現死迴圈，因為使用者輸入任意資料後，資料被送入buffer且沒有被讀出，所以lt模式下每次epoll_wait都認為buffer可讀返回讀就緒。導致每次都會輸出」hello world！」。下面在看程式二。
l 程式二
#include
#include
#include
using namespace std;
int main(void)}}
}執行結果：
程式二依然使用lt模式，但是每次epoll_wait返回讀就緒的時候我們都將buffer（緩衝）中的內容read出來，所以導致buffer再次清空，下次呼叫epoll_wait就會阻塞。所以能夠實現我們所想要的功能——當使用者從控制台有任何輸入操作時，輸出」hello world！」。我們再來看看程式三。
l 程式三
程式三依然使用et，但是每次讀就緒後都主動的再次mod in事件，我們發現程式再次出現死迴圈，也就是每次返回讀就緒。這就驗證了上一節討論et讀就緒的第三種情況。但是注意，如果我們將mod改為add，將不會產生任何影響。別忘了每次add乙個描述符都會在epitem組成的紅黑樹中新增乙個項，我們之前已經add過一次，再次add將阻止新增，所以在次呼叫add in事件不會有任何影響。
徹底學會使用epoll（四） ET的寫操作例項分析
風吹過夏天的chinaunix部落格 首先，看程式四的例子。l 程式四 include include include using namespace std int main void 這個程式的功能是只要標準輸出寫就緒，就輸出 hello world！執行結果 我們發現這將是乙個死迴圈。下面具體...
乙個sample學會使用epoll
include include include include include include include include include include include include define max event number 1024 define tcp buffer size 51...
徹底學會使用JS中 和 以及 和
console.log 1 2 console.log 1 2 上面列印的結果是什麼呢？運算方法 只要 前面為false,不管 後面是true還是false，都返回 後面的值。只要 前面為true,不管 後面是true還是false，都返回 前面的值。總結 真前假後運算方法 只要 前面是false，...