今天给各位分享linux下如何创建事件的知识，其中也会对Linux 事件进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录一览：
linux 事件如何触发
linux的事件可以通过信号产生。
你说的比较笼统，我也不知道你说的是哪一种。
linux下可以给任何进程发送一些信号，进程收到信号后，需要执行一些操作，这个和Win32下的事件有点像。但是这个是系统级的。
你如果是要编写一个大型程序，分成各个模块，那么各模块之间不但可以用信号来传递消息，也可以用SystemV自带的消息队列或者socket来传递消息，以达到与“触发事件”类似的效果。
进程也可以给自己发信号，也可以给自己发消息（通过消息队列）。
如何在linux下实现event事件机制
内部使用select、epoll、kqueue等系统调用管理事件机制只提供了简单的网络API的封装,线程池,内存池,递归辅助功能函数、日志、libevent框架、对系 统I/O如何在linux下实现event事件机制
Handler消息机制（一）：Linux的epoll机制
在linux 没有实现epoll事件驱动机制之前，我们一般选择用select或者poll等IO多路复用的方法来实现并发服务程序。在linux新的内核中，有了一种替换它的机制，就是epoll。
相比select模型， poll使用链表保存文件描述符，因此没有了监视文件数量的限制 ，但其他三个缺点依然存在。
假设我们的服务器需要支持100万的并发连接，则在__FD_SETSIZE 为1024的情况下，则我们至少需要开辟1k个进程才能实现100万的并发连接。除了进程间上下文切换的时间消耗外，从内核/用户空间大量的无脑内存拷贝、数组轮询等，是系统难以承受的。因此，基于select模型的服务器程序，要达到10万级别的并发访问，是一个很难完成的任务。
由于epoll的实现机制与select/poll机制完全不同，上面所说的 select的缺点在epoll上不复存在。
设想一下如下场景：有100万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻，通常只有几百上千个TCP连接是活跃的(事实上大部分场景都是这种情况)。如何实现这样的高并发？
在select/poll时代，服务器进程每次都把这100万个连接告诉操作系统(从用户态复制句柄数据结构到内核态)，让操作系统内核去查询这些套接字上是否有事件发生，轮询完后，再将句柄数据复制到用户态，让服务器应用程序轮询处理已发生的网络事件，这一过程资源消耗较大，因此，select/poll一般只能处理几千的并发连接。
epoll的设计和实现与select完全不同。epoll通过在Linux内核中申请一个简易的文件系统(文件系统一般用什么数据结构实现？B+树)。把原先的select/poll调用分成了3个部分：
1）调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)
2）调用epoll_ctl向epoll对象中添加这100万个连接的套接字
3）调用epoll_wait收集发生的事件的连接
如此一来，要实现上面说是的场景，只需要在进程启动时建立一个epoll对象，然后在需要的时候向这个epoll对象中添加或者删除连接。同时，epoll_wait的效率也非常高，因为调用epoll_wait时，并没有一股脑的向操作系统复制这100万个连接的句柄数据，内核也不需要去遍历全部的连接。
当某一进程调用epoll_create方法时，Linux内核会创建一个eventpoll结构体，这个结构体中有两个成员与epoll的使用方式密切相关。eventpoll结构体如下所示：
每一个epoll对象都有一个独立的eventpoll结构体，用于存放通过epoll_ctl方法向epoll对象中添加进来的事件。这些事件都会挂载在红黑树中，如此，重复添加的事件就可以通过红黑树而高效的识别出来(红黑树的插入时间效率是lgn，其中n为树的高度)。
而所有 添加到epoll中的事件都会与设备(网卡)驱动程序建立回调关系，也就是说，当相应的事件发生时会调用这个回调方法 。这个回调方法在内核中叫ep_poll_callback,它会将发生的事件添加到rdlist双链表中。
在epoll中，对于每一个事件，都会建立一个epitem结构体，如下所示：
当调用epoll_wait检查是否有事件发生时，只需要检查eventpoll对象中的rdlist双链表中是否有epitem元素即可。如果rdlist不为空，则把发生的事件复制到用户态，同时将事件数量返回给用户。
epoll结构示意图
通过红黑树和双链表数据结构，并结合回调机制，造就了epoll的高效。
events可以是以下几个宏的集合：
EPOLLIN：触发该事件，表示对应的文件描述符上有可读数据。(包括对端SOCKET正常关闭)；
EPOLLOUT：触发该事件，表示对应的文件描述符上可以写数据；
EPOLLPRI：表示对应的文件描述符有紧急的数据可读（这里应该表示有带外数据到来）；
EPOLLERR：表示对应的文件描述符发生错误；
EPOLLHUP： 表示对应的文件描述符被挂断；
EPOLLET：将EPOLL设为边缘触发(EdgeTriggered)模式，这是相对于水平触发(Level Triggered)来说的。
EPOLLONESHOT： 只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个socket的话，需要再次把这个socket加入到EPOLL队列里。
示例：
ET(EdgeTriggered) :高速工作模式，只支持no_block(非阻塞模式)。在此模式下，当描述符从未就绪变为就绪时，内核通过epoll告知。然后它会假设用户知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到某些操作导致那个文件描述符不再为就绪状态了。(触发模式只在数据就绪时通知一次，若数据没有读完，下一次不会通知，直到有新的就绪数据)
LT(LevelTriggered) :缺省工作方式，支持blocksocket和no_blocksocket。在LT模式下内核会告知一个文件描述符是否就绪了，然后可以对这个就绪的fd进行IO操作。如果不作任何操作，内核还是会继续通知！若数据没有读完，内核也会继续通知，直至设备数据为空为止！
1.我们已经把一个用来从管道中读取数据的文件句柄(RFD)添加到epoll描述符
\2. 这个时候从管道的另一端被写入了2KB的数据
\3. 调用epoll_wait(2)，并且它会返回RFD，说明它已经准备好读取操作
\4. 然后我们读取了1KB的数据
\5. 调用epoll_wait(2)……
ET工作模式：
如果我们在第1步将RFD添加到epoll描述符的时候使用了EPOLLET标志，在第2步执行了一个写操作，第三步epoll_wait会返回同时通知的事件会销毁。因为第4步的读取操作没有读空文件输入缓冲区内的数据，因此我们在第5步调用epoll_wait(2)完成后，是否挂起是不确定的。epoll工作在ET模式的时候，必须使用非阻塞套接口，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。
只有当read(2)或者write(2)返回EAGAIN时(认为读完)才需要挂起，等待。但这并不是说每次read()时都需要循环读，直到读到产生一个EAGAIN才认为此次事件处理完成，当read()返回的读到的数据长度小于请求的数据长度时(即小于sizeof(buf))，就可以确定此时缓冲中已没有数据了，也就可以认为此事读事件已处理完成。
LT工作模式：
LT方式调用epoll接口的时候，它就相当于一个速度比较快的poll(2)，并且无论后面的数据是否被使用，因此他们具有同样的职能。
当调用 epoll_wait检查是否有发生事件的连接时，只是检查 eventpoll对象中的 rdllist双向链表是否有 epitem元素而已，如果 rdllist链表不为空，则把这里的事件复制到用户态内存中，同时将事件数量返回给用户。因此，epoll_wait的效率非常高。epoll_ctl在向 epoll对象中添加、修改、删除事件时，从 rbr红黑树中查找事件也非常快，也就是说，epoll是非常高效的，它可以轻易地处理百万级别的并发连接。
1.减少用户态和内核态之间的文件句柄拷贝；
2.减少对可读可写文件句柄的遍历。
;wfr=spiderfor=pc
关于Linux下的select/epoll
select这个系统调用的原型如下
第一个参数nfds用来告诉内核 要扫描的socket fd的数量+1 ，select系统调用最大接收的数量是1024，但是如果每次都去扫描1024，实际上的数量并不多，则效率太低，这里可以指定需要扫描的数量。 最大数量为1024，如果需要修改这个数量，则需要重新编译Linux内核源码。
第2、3、4个参数分别是readfds、writefds、exceptfds，传递的参数应该是fd_set 类型的引用，内核会检测每个socket的fd， 如果没有读事件，就将对应的fd从第二个参数传入的fd_set中移除，如果没有写事件，就将对应的fd从第二个参数的fd_set中移除，如果没有异常事件，就将对应的fd从第三个参数的fd_set中移除 。这里我们应该 要将实际的readfds、writefds、exceptfds拷贝一份副本传进去，而不是传入原引用，因为如果传递的是原引用，某些socket可能就已经丢失 。
最后一个参数是等待时间， 传入0表示非阻塞，传入0表示等待一定时间，传入NULL表示阻塞，直到等到某个socket就绪 。
FD_ZERO()这个函数将fd_set中的所有bit清0，一般用来进行初始化等。
FD_CLR()这个函数用来将bitmap(fd_set )中的某个bit清0，在客户端异常退出时就会用到这个函数，将fd从fd_set中删除。
FD_ISSET()用来判断某个bit是否被置1了，也就是判断某个fd是否在fd_set中。
FD_SET()这个函数用来将某个fd加入fd_set中，当客户端新加入连接时就会使用到这个函数。
epoll_create系统调用用来创建epfd，会在开辟一块内存空间(epoll的结构空间)。size为epoll上能关注的最大描述符数，不够会进行扩展，size只要＞0就行，早期的设计size是固定大小，但是现在size参数没什么用，会自动扩展。
返回值是epfd，如果为-1则说明创建epoll对象失败 。
第一个参数epfd传入的就是epoll_create返回的epfd。
第二个参数传入对应操作的宏，包括 增删改(EPOLL_CTL_ADD、EPOLL_CTL_DEL、EPOLL_CTL_MOD) 。
第三个参数传入的是 需要增删改的socket的fd 。
第四个参数传入的是 需要操作的fd的哪些事件 ，具体的事件可以看后续。
返回值是一个int类型，如果为-1则说明操作失败 。
第一个参数是epfd，也就是epoll_create的返回值。
第二个参数是一个epoll_event类型的指针，也就是传入的是一个数组指针。 内核会将就绪的socket的事件拷贝到这个数组中，用户可以根据这个数组拿到事件和消息等 。
第三个参数是maxevents，传入的是 第二个参数的数组的容量 。
第四个参数是timeout， 如果设为-1一直阻塞直到有就绪数据为止，如果设为0立即返回，如果＞0那么阻塞一段时间 。
返回值是一个int类型，也就是就绪的socket的事件的数量(内核拷贝给用户的events的元素的数量)，通过这个数量可以进行遍历处理每个事件 。
一般需要传入 ev.data.fd 和 ev.events ，也就是fd和需要监控的fd的事件。事件如果需要传入多个，可以通过按位与来连接，比如需要监控读写事件，只需要像如下这样操作即可： ev.events=EPOLLIN | EPOLLOUT 。
LT(水平触发)， 默认 的工作模式， 事件就绪后用户可以选择处理和不处理，如果用户不处理，内核会对这部分数据进行维护，那么下次调用epoll_wait()时仍旧会打包出来 。
ET(边缘触发)，事件就绪之后， 用户必须进行处理 ，因为内核把事件打包出来之后就把对应的就绪事件给清掉了， 如果不处理那么就绪事件就没了 。ET可以减少epoll事件被重复触发的次数，效率比LT高。
如果需要设置为边缘触发只需要设置事件为类似 ev.events=EPOLLIN | EPOLLET 即可 。
select/poll/epoll是nio多路复用技术， 传统的bio无法实现C10K/C100K ，也就是无法满足1w/10w的并发量，在这么高的并发量下，在进行上下文切换就很容易将服务器的负载拉飞。
1.将fd_set从用户态拷贝到内核态
2.根据fd_set扫描内存中的socket的fd的状态，时间复杂度为O(n)
3.检查fd_set，如果有已经就绪的socket，就给对应的socket的fd打标记，那么就return 就绪socket的数量并唤醒当前线程，如果没有就绪的socket就继续阻塞当前线程直到有socket就绪才将当前线程唤醒。
4.如果想要获取当前已经就绪的socket列表，则还需要进行一次系统调用，使用O(n)的时间去扫描socket的fd列表，将已经打上标记的socket的fd返回。
CPU在同一个时刻只能执行一个程序，通过RR时间片轮转去切换执行各个程序。没有被挂起的进程(线程)则在工作队列中排队等待CPU的执行，将进程(线程)从工作队列中移除就是挂起，反映到Java层面的就是线程的阻塞。
什么是中断？当我们使用键盘、鼠标等IO设备的时候，会给主板一个电流信号，这个电流信号就给CPU一个中断信号，CPU执行完当前的指令便会保存现场，然后执行键盘/鼠标等设备的中断程序，让中断程序获取CPU的使用权，在中断程序后又将现场恢复，继续执行之前的进程。
如果第一次没检测到就绪的socket，就要将其进程(线程)从工作队列中移除，并加入到socket的等待队列中。
socket包含读缓冲区+写缓冲区+等待队列(放线程或eventpoll对象)
当从客户端往服务器端发送数据时，使用TCP/IP协议将通过物理链路、网线发给服务器的网卡设备，网卡的DMA设备将接收到的的数据写入到内存中的一块区域(网卡缓冲区)，然后会给CPU发出一个中断信号，CPU执行完当前指令则会保存现场，然后网卡的中断程序就获得了CPU的使用权，然后CPU便开始执行网卡的中断程序，将内存中的缓存区中的数据包拿出，判断端口号便可以判断它是哪个socket的数据，将数据包写入对应的socket的读(输入)缓冲区，去检查对应的socket的等待队列有没有等待着的进程(线程)，如果有就将该线程(进程)从socket的等待队列中移除，将其加入工作队列，这时候该进程(线程)就再次拥有了CPU的使用权限，到这里中断程序就结束了。
之后这个进程(线程)就执行select函数再次去检查fd_set就能发现有socket缓冲区中有数据了，就将该socket的fd打标记，这个时候select函数就执行完了，这时候就会给上层返回一个int类型的数值，表示已经就绪的socket的数量或者是发生了错误。这个时候就再进行内核态到用户态的切换，对已经打标记的socket的fd进行处理。
将原本1024bit长度的bitmap(fd_set)换成了数组的方式传入 ，可以 解决原本1024个不够用的情况 ，因为传入的是数组，长度可以不止是1024了，因此socket数量可以更多，在Kernel底层会将数组转换成链表。
在十多年前，linux2.6之前，不支持epoll，当时可能会选择用Windows/Unix用作服务器，而不会去选择Linux，因为select/poll会随着并发量的上升，性能变得越来越低，每次都得检查所有的Socket列表。
1.select/poll每次调用都必须根据提供所有的socket集合，然后就 会涉及到将这个集合从用户空间拷贝到内核空间，在这个过程中很耗费性能 。但是 其实每次的socket集合的变化也许并不大，也许就1-2个socket ，但是它会全部进行拷贝，全部进行遍历一一判断是否就绪。
2.select/poll的返回类型是int，只能代表当前的就绪的socket的数量/发生了错误， 如果还需要知道是哪些socket就绪了，则还需要再次使用系统调用去检查哪些socket是就绪的，又是一次O(n)的操作，很耗费性能 。
1.epoll在Kernel内核中存储了对应的数据结构(eventpoll)。我们可以 使用epoll_create()这个系统调用去创建一个eventpoll对象 ，并返回eventpoll的对象id(epfd)，eventpoll对象主要包括三个部分：需要处理的正在监听的socket_fd列表(红黑树结构)、socket就绪列表以及等待队列(线程)。
2.我们可以使用epoll_ctl()这个系统调用对socket_fd列表进行CRUD操作，因为可能频繁地进行CRUD，因此 socket_fd使用的是红黑树的结构 ，让其效率能更高。epoll_ctl()传递的参数主要是epfd(eventpoll对象id)。
3.epoll_wait()这个系统调用默认会 将当前进程(线程)阻塞，加入到eventpoll对象的等待队列中，直到socket就绪列表中有socket，才会将该进程(线程)重新加入工作队列 ，并返回就绪队列中的socket的数量。
socket包含读缓冲区、写缓冲区和等待队列。当使用epoll_ctl()系统调用将socket新加入socket_fd列表时，就会将eventpoll对象引用加到socket的等待队列中， 当网卡的中断程序发现socket的等待队列中不是一个进程(线程)，而是一个eventpoll对象的引用，就将socket引用追加到eventpoll对象的就绪列表的尾部 。而eventpoll对象中的等待队列存放的就是调用了epoll_wait()的进程(线程)，网卡的中断程序执行会将等待队列中的进程(线程)重新加入工作队列，让其拥有占用CPU执行的资格。epoll_wait()的返回值是int类型，返回的是就绪的socket的数量/发生错误，-1表示发生错误。
epoll的参数有传入一个epoll_event的数组指针(作为输出参数)，在调用epoll_wait()返回的同时，Kernel内核还会将就绪的socket列表添加到epoll_event类型的数组当中。
关于linux下如何创建事件和Linux 事件的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。