将晦涩难懂的技术讲的通俗易懂
分类: LINUX
2014-06-06 00:01:13
首先看程序一,这个程序想要实现的功能是当用户从控制台有任何输入操作时,输出”hello world!”。
l 程序一
点击(此处)折叠或打开
运行结果:
程序一中对标准输入的监听使用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 程序二
点击(此处)折叠或打开
运行结果:
程序二依然使用LT模式,但是每次epoll_wait返回读就绪的时候我们都将buffer(缓冲)中的内容read出来,所以导致buffer再次清空,下次调用epoll_wait就会阻塞。所以能够实现我们所想要的功能——当用户从控制台有任何输入操作时,输出”hello world!”。我们再来看看程序三。
l 程序三
点击(此处)折叠或打开
程序三依然使用ET,但是每次读就绪后都主动的再次MOD IN事件,我们发现程序再次出现死循环,也就是每次返回读就绪。这就验证了上一节讨论ET读就绪的第三种情况。但是注意,如果我们将MOD改为ADD,将不会产生任何影响。别忘了每次ADD一个描述符都会在epitem组成的红黑树中添加一个项,我们之前已经ADD过一次,再次ADD将阻止添加,所以在次调用ADD IN事件不会有任何影响。
KingaChou2015-09-02 14:30:30
博主好,我复制张贴了程序一代码到我的虚拟机上。结果却是死循环输出hello world。百思不得其解。系统版本如下:
LSB Version: :core-4.0-amd64:core-4.0-ia32:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-ia32:printing-4.0-noarch
Distributor ID: CentOS
Description: CentOS release 5.10 (Final)
Release: 5.10
Codename: Final