1.Gevent源码剖析（二）：Gevent 运行原理
2.gem5 源码阅读 之 event
3.Vert.x 源码解析(4.x)——Future源码解析
4.redis源码解读（一）：事件驱动的事件事件io模型，为什么，驱动驱动是源码源码什么，怎么做
5.libevent、事件事件libev框架介绍
6.让事件飞 ——Linux eventfd 原理与实践

Gevent源码剖析（二）：Gevent 运行原理

       Gevent的运行原理在python2.7.5版本下，涉及多个关键概念。源码源码搞笑 社区 源码简单来说，事件事件它通过Greenlet类和Hub事件循环实现并发执行。驱动驱动以下是源码源码核心步骤：

       首先，通过导入gevent模块，事件事件引入其初始化设置，驱动驱动greenlet的源码源码运行函数通过gevent.spawn()方法注册到Hub，这个过程包括获取Hub实例、事件事件初始化greenlet并保存函数和参数。驱动驱动get_hub()利用线程局部存储保证Hub的源码源码多线程一致性。

       接着，greenlet通过g.start()注册到事件循环，回调事件由switch()控制，而不是直接运行函数，实现了协程的切换。Gevent提供了join()和joinall()两个入口，其中joinall()控制了整个流程。

       在详细流程中，iwait()函数扮演重要角色，通过创建Waiter对象，将协程的switch()链接到目标，通过waiter.get()控制协程执行和返回。Hub事件循环与运行协程通过waiter.get()和waiter.switch()协同工作，实现了并发执行。

       目标协程的执行涉及事件循环的启动，通过Cython调用libev库执行。目标函数在run()中执行，并通过_report_result()和_report_error()处理结果或异常。"绿化"函数是实现并发的关键，它们允许在等待I/O操作时释放控制权，从而实现多任务并发。

       总的来说，Gevent的运行涉及复杂的协程调度和事件驱动，虽然本文仅触及表面，但其背后的并发机制和技术细节更为丰富，包括异常处理和大量"绿化"函数的使用，这将在后续深入探讨。

gem5 源码阅读 之 event

       Event在gem5中扮演核心角色，本文将聚焦几个关键问题的解答：

       gem5作为事件驱动型仿真器，能高效处理每个动作或响应，无需频繁检查全局时间，显著降低执行时间。每个继承自EventManager的SimObject实例均可承担事件管理职责。

       SimObject的schedule方法将事件排序并插入全局EventQueue，构建全局事件树。Event执行基于排序后的when+priority值，确保事件有序执行。小熊投票平台源码

       以cache为例，事件注册流程始于DCachePort的recvTimingResp函数中的tickEvent自身调用schedule方法，进一步由cpu调用schedule，实际上就是EventManager的schedule函数，将事件插入到event queue中。

       事件的执行时机取决于其特性，如cache中的tickEvent执行数据传输动作，通常在recvTimingResp函数中触发，此时代表完整数据请求完成的事件点。

       事件树的执行依赖于event queue管理，主event queue在doSimLoop中处理，其他event queue通过thread_loop并行处理，并通过threadBarrier同步所有线程，确保事件同时执行。

       全局eventqueue通过getEventQueue函数生成，参数index指定queue索引，第一次使用时创建新对象，每个queue与一个线程关联，执行相关事件。

       EventQueue创建在不同使用场景中，例如cxx_config方式下，在main.cc文件中直接调用getEventQueue，生成全局eventqueue；gem5 within systemc方式下，在main.cc中实例化SimControl对象，进而调用simulate函数，管理全局eventqueue。

       在Python配置文件中，如fs.py，通过build_test_system函数构建系统组件，cpu的eventq_index参数用于创建全局eventqueue，确保所有相关组件事件同步。

       综上所述，gem5通过事件驱动机制高效仿真系统行为，事件注册、执行、管理流程贯穿整个系统仿真过程，确保复杂系统行为的准确模拟。

Vert.x 源码解析(4.x)——Future源码解析

       在现代软件开发中，异步编程的重要性日益凸显，提升并发性能并处理大量并行操作。Vert.x，作为一款基于事件驱动和非阻塞设计的异步框架，提供了丰富的工具简化异步编程。本文将深入解析Vert.x 4.x版本的Future源码，理解其关键类和功能。

       1. 异步核心

       Vert.x的核心在于FutureImpl和PromiseImpl，它们是实现异步操作的关键。AsyncResult是通用接口，用于表示异步操作的结果，包含成功值或失败异常。

       2. Future类详解

       Future扩展了AsyncResult，复杂bias指标源码提供了组合操作如join、any、all和map等功能。内部的FutureInternal主要负责添加监听器，FutureBase负责执行监听器和转换函数。

       具体来说，FutureImpl的onComplete方法接收一个handler，任务完成后执行，而tryComplete则在异步操作有结果时触发，最终调用用户指定的handler。

       相比之下，Promise允许用户手动设置异步结果，PromiseImpl继承自FutureImpl，并增加了context获取功能。

       3. 实例与源码分析

       通过简单的入门实例，如独立使用Future，我们可以看到Vert.x如何通过创建PromiseImpl获取Future。源码分析显示，Promise.future获取Future，OnComplete用于添加监听，而complete方法则用于设置值并通知监听器。

       4. 深入源码

       在源码层面，addListener和emitSuccess方法在OnComplete中扮演重要角色。而complete方法，特别是tryComplete，是设置值并触发监听的关键。

       5. 总结

       总的来说，理解Vert.x中的Future，就是创建PromiseImpl获取Future，通过OnComplete添加监听器，然后通过Promise的complete方法设置值并通知监听器。后续还将深入探讨其他Future实现类，如all、any和map的原理。

redis源码解读（一）：事件驱动的io模型，为什么，是什么，怎么做

       Redis作为一个高性能的内存数据库，因其出色的读写性能和丰富的数据结构支持，已成为互联网应用不可或缺的中间件之一。阅读其源码，可以了解其内部针对高性能和分布式做的种种设计，包括但不限于reactor模型（单线程处理大量网络连接），定时任务的实现（面试常问），分布式CAP BASE理论的实际应用，高效的数据结构的实现，其次还能够通过大神的代码学习C语言的编码风格和技巧，让自己的代码更加优雅。

       下面进入正题：为什么需要事件驱动的io模型

       我们可以简单地将一个服务端程序拆成三部分，接受请求->处理请求->返回结果，其中接收请求和处理请求便是163邮箱生成源码我们常说的网络io。那么网络io如何实现呢，首先我们介绍最基础的io模型，同步阻塞式io，也是很多同学在学校所学的“网络编程”。

       使用同步阻塞式io的单线程服务端程序处理请求大致有以下几个步骤

       其中3,4步都有可能使线程阻塞（6也会可能阻塞，这里先不讨论）

       在第3步，如果没有客户端请求和服务端建立连接，那么服务端线程将会阻塞。如果redis采用这种io模型，那主线程就无法执行一些定时任务，比如过期key的清理，持久化操作，集群操作等。

       在第4步，如果客户端已经建立连接但是没有发送数据，服务端线程会阻塞。若说第3步所提到的定时任务还可以通过多开两个线程来实现，那么第4步的阻塞就是硬伤了，如果一个客户端建立了连接但是一直不发送数据，服务端便会崩溃，无法处理其他任何请求。所以同步阻塞式io肯定是不能满足互联网领域高并发的需求的。

       下面给出一个阻塞式io的服务端程序示例：

       刚才提到，阻塞式io的主要问题是，调用recv接收客户端请求时会导致线程阻塞，无法处理其他客户端请求。那么我们不难想到，既然调用recv会使线程阻塞，那么我们多开几个几个线程不就好了，让那些没有阻塞的线程去处理其他客户端的请求。

       我们将阻塞式io处理请求的步骤改造下：

       改造后，我们用一个线程去做accept，也就是获取已经建立的连接，我们称这个线程为主线程。然后获取到的每个连接开一个新的线程去处理，这样就能够将阻塞的部分放到新的线程，达到不阻塞主线程的目的，主线程仍然可以继续接收其他客户端的连接并开新的线程去处理。这个方案对高并发服务器来说是一个可行的方案，此外我们还可以使用线程池等手段来继续优化，减少线程建立和销毁的开销。

       将阻塞式io改为多线程io：

       我们刚才提到多线程可以解决并发问题，然而redis6.0之前使用的是单线程来处理，之所以用单线程，官方给的答复是redis的瓶颈不在cpu，既然不在cpu那么用单线程可以降低系统的复杂度，避免线程同步等问题。如何在一个线程中非阻塞地处理多个socket，进而实现多个客户端的并发处理呢，那就要借助io多路复用了。

       io多路复用是声控命令识别源码操作系统提供的另一种io机制，这种机制可以实现在一个线程中监控多个socket，返回可读或可写的socket，当一个socket可读或可写时再去操作它，这样就避免了对某个socket的阻塞等待。

       将多线程io改为io多路复用：

       什么是事件驱动的io模型（Reactor）

       这里只讨论redis用到的单线程Reactor模型

       事件驱动的io模型并不是一个具体的调用，而是高并发服务器的一种抽象的编程模式。

       在Reactor模型中，有三种事件：

       与这三种事件对应的，有三种handler，负责处理对应的事件。我们在一个主循环中不断判断是否有事件到来（一般通过io多路复用获取事件），有事件到来就调用对应的handler去处理时间。

       听着玄乎，实际上也就这一张图：

       事件驱动的io模型在redis中的实现

       以下提及的源码版本为 5.0.8

       文字的苍白的，建议参照本文最后的方法下载代码，自己调试下

       整体框架

       redis-server的main方法在 src/server.c 最后，在main方法中，首先进行一系列的初始化操作，最后进入进入Reactor模型的主循环中：

       主循环在aeMain函数中，aeMain函数传入的参数 server.el ，是一个 aeEventLoop 类型的全局变量，保存了主循环的一些状态信息，包括需要处理的读写事件、时间事件列表，epoll相关信息，回调函数等。

       aeMain函数中，我们可以看到当 eventLoop->stop 标志位为0时，while循环中的内容会被重复执行，每次循环首先会调用beforesleep回调函数，然后处理时间。beforesleep函数在main函数中被注册，会进行集群状态更新、AOF落盘等任务。

       之所以叫beforesleep，是因为aeProcessEvents函数中包含了获取事件和处理事件的逻辑，其中获取读写事件时通过epoll_wait实现，会将线程阻塞。

       在aeProcessEvents函数中，处理读写事件和时间事件，参数flags定义了需要处理的事件类型，我们可以暂时忽略这个参数，认为读写时间都需要处理。

       aeProcessEvents函数的逻辑可以分为三个部分，首先获取距离最近的时间事件，这一步的目的是为了确定epoll_wait的超时时间，并不是实际处理时间事件。

       第二个部分为获取读写事件并处理，首先调用epoll_wait，获取需要处理的读写事件，超时时间为第一步确定的时间，也就是说，如果在超时时间内有读写事件到来，那么处理读写时间，如果没有读写时间就阻塞到下一个时间事件到来，去处理时间事件。

       第三个部分为处理时间事件。

       事件注册与获取

       上面我们讲了整体框架，了解了主循环的大致流程。接下来我们来看其中的细节，首先是读写事件的注册与获取。

       redis将读、写、连接事件用结构aeFileEvent表示，因为这些事件都是通过epoll_wait获取的。

       事件的具体类型通过mask标志位来区分。aeFileEvent还保存了事件处理的回调函数指针（rfileProc、wfileProc）和需要读写的数据指针（clientData）。

       既然读写事件是通过epoll io多路复用实现，那么就避不开epoll的三部曲 epoll_create epoll_ctrl epoll_wait，接下来我们看下redis对epoll接口的封装。

       我们之前提到aeMain函数的参数是一个 aeEventLoop 类型的全局变量，aeEventLoop中保存了epoll文件描述符和epoll事件。在aeApiCreate函数（src/ae_epoll.c）中，会调用epoll_create来创建初始化epoll文件描述符和epoll事件，调用关系为 main -> initServer -> aeCreateEventLoop -> aeApiCreate

       调用epoll_create创建epoll后，就可以添加需要监控的文件描述符了，需要监控的情形有三个，一是监控新的客户端连接连接请求，二是监控客户端发送指令，也就是读事件，三是监控客户端写事件，也就是处理完了请求写回结果。

       这三种情形在redis中被抽象为文件事件，文件事件通过函数aeCreateFileEvent（src/ae.c）添加，添加一个文件事件主要包含三个步骤，通过epoll_ctl添加监控的文件描述符，指定回调函数和指定读写缓冲区。

       最后是通过epoll_wait来获取事件，上文我们提到，在每次主循环中，首先根据最近到达的时间事件来计算epoll_wait的超时时间，然后调用epoll_wait获取事件，再处理事件，其中获取事件在函数aeApiPoll（src/ae_epoll.c）中。

       获取到事件后，主循环中会逐个调用事件的回调函数来处理事件。

       读写事件的实现

       写累了，有空补上……

       如何使用vscode调试redis源码

       编译出二进制程序

       这一步有可能报错：

       jemalloc是内存分配的一种更高效的实现，用于代替libc的默认实现。这里报错找不到jemalloc，我们只需要将其替换成libc默认实现就好：

       如果报错：

       我们可以在src目录找到一个脚本名为mkreleasehdr.sh，其中包含创建release.h的逻辑，将报错信息网上翻可以发现有一行：

       看来是这个脚本没有执行权限，导致release.h没有成功创建，我们需要给这个脚本添加执行权限然后重新编译：

       2. 创建调试配置（vscode）

       创建文件 .vscode/launch.json，并填入以下内容：

       然后就可以进入调试页面打断点调试了，main函数在 src/server.c

libevent、libev框架介绍

       本文深入讲解了libevent的API，并剖析了libevent的evbuffer源码。libevent、libev和libuv都是C语言实现的异步事件库，主要负责注册异步事件、检测异步事件，并根据事件的触发先后顺序调用相应的回调函数处理事件。这些事件包括网络I/O事件、定时事件以及信号事件，共同驱动服务器运行。

       libevent和libev主要封装了与操作系统交互的简单事件管理接口，让开发者无需关注平台差异，只需处理事件的具体逻辑。libev改进了libevent的架构决策，如消除全局变量的使用，采用回调函数传递上下文，构建不同的数据结构以降低事件耦合性，使用最小四叉堆作为计时器，从而实现高效管理。然而，libevent和libev在window平台的支持较差，因此libuv应运而生，基于libev，尤其在window平台上更好地封装了iocp，node.js即基于libuv。

       在libevent的编译安装过程中，首先从git下载release-2.1.-stable.tar.gz，然后在编译程序时指定库名：-levent。由于头文件和库文件已经复制至系统路径，因此在编译时无需额外指定-I和-L。

       libevent的封装层次分为网络封装和解决的问题。网络封装包括IO检测和IO操作，解决的问题涉及连接建立（如最大连接数、黑白名单等）和连接断开，以及数据的到达与发送。如果不想手动操作IO事件，libevent会管理读写I/O处理，使开发者只需处理逻辑，无需关心边界问题。

       libevent提供了事件检测与操作的封装。事件检测是低层封装，由libevent负责，用户自定义IO操作。该层次封装了事件管理器操作和事件接口。事件管理器event_base用于构建事件集合，检测事件就绪情况。释放管理器使用event_base_free，event_reinit用于重置，event_get_supported_methods查看支持的方法。

       事件循环通过event_base_dispatch和event_base_loop实现，等待事件产生，提供类似epoll红黑树循环的功能。事件循环终止使用event_base_loopbreak和event_base_loopexit，前者在事件回调执行后终止，后者立即终止。

       事件对象通过event_new创建，event_free销毁。注册与注销事件使用event_add和event_del，事件驱动的核心思想是libevent的核心功能。

       libevent事件对象包括只使用事件检测、IO操作自处理的Demo。此外，自带缓冲的事件-bufferevent介绍其作为event的高级版本，拥有两个缓冲区和三个回调函数，分别用于读取、写入和事件处理。

       bufferevent提供读写数据到缓冲区的封装，三个回调函数分别处理读取、写入和事件触发。构建、销毁bufferevent对象，以及连接操作、设置回调等。

       事件类型注册与注销使用bufferevent_enable/disable，获取读写缓冲区使用bufferevent_get_input和bufferevent_get_output，数据分割使用evbuffer_readln和固定长度读取使用evbuffer_remove。

       对于bufferevent，一个文件描述符对应两个缓冲区和三个回调函数，文件描述符用于与客户端通信，非监听文件描述符。两个缓冲区指读缓冲区和写缓冲区，三个回调分别对应读操作、写操作和事件触发。

       链接监听器-evconnlistener封装底层socket通信函数，如socket、bind、listen、accept。创建监听器后，等待新客户端连接，调用用户指定的回调函数。构建监听器使用evconnlistener_new_bind，回调函数evconnlistener_cb接收与客户端通信的描述符和连接对端地址。

       信号事件在libevent中与网络事件相似，通过epoll监听。定时事件和网络事件的处理机制基于最小堆与epoll_wait，通过源码分析可深入了解流程。

       evbuffer作为libevent底层实现的链式缓冲区，用于bufferevent事件中的数据读写。每个evbuffer由链表组成，包含关键成员和实现细节。evbuffer的优点在于高效处理数据移动和内存浪费，缺点是数据在不连续内存中存储，可能导致多次io。libev关注具体网络IO事件、定时事件和信号事件，提供API如ev_io_init、ev_io_start、ev_timer_start和ev_run。通过libev宏定义封装，开发者能使用与libevent类似的接口。

让事件飞 ——Linux eventfd 原理与实践

       在当今的程序设计中，事件驱动的方式变得越来越普遍。为了有效地利用系统资源并实现通知的管理和送达，Linux 系统中提供了事件通知的机制，如 eventfd 和 timerfd。这两个机制，前者用于触发事件通知，后者则用于定时器事件通知。

       使用 eventfd 时，开发者只需包含相应的头文件即可。创建一个 eventfd 对象，类似于普通文件的 open 操作，该对象内部维护一个无符号的 位计数器，初始化值为用户指定。事件通知可通过两种操作实现：read 操作将计数器值置零，而 write 操作用于设置计数器值。同时，该对象支持 epoll/poll/select 操作，以及关闭操作。

       对于 timerfd，开发者需调用 timerfd_create 函数创建新的 timerfd 对象，指定时钟类型，通常选择实时时钟（CLOCK_REALTIME）或单调递增时钟（CLOCK_MONOTONIC）。timerfd_settime 函数用于设置定时器的过期时间，其中包含首次过期时间及周期性触发的间隔时间。timerfd_gettime 函数用于获取当前设置值，而 read 操作返回已过期的次数或阻塞至过期，取决于是否设置了 NONBLOCK 标志。

       使用实例展示了如何实现高性能的消费者线程池，通过生产者-消费者设计模式，将 eventfd 和 timerfd 用于事件通知。消费者线程池中的线程共用一个 epoll 对象，通过 epoll_wait 以轮询方式处理针对 eventfd 或 timerfd 触发的事件。在 eventfd 实现中，推荐在打开时设置 NON_BLOCKING，并在 epoll 监听对象上设置 EPOLLET，以发挥非阻塞 IO 和边沿触发的最大并发能力。

       在 timerfd 实现中，main 函数和消费者线程与 eventfd 类似，而生产者线程则创建 timerfd 并将其注册到事件循环中。timer 的 it_value 设为 1 秒，it_interval 设为 3 秒，用于设置定时器事件。执行过程与 eventfd 类似，通过 epoll 监控 timerfd 触发的事件。

       事件通知场景中，使用 eventfd/timerfd 相较于 pipe 有显著的优势，主要体现在资源管理和性能方面。在信号通知场景下，eventfd/timerfd 与 pipe 相比，提供了更高效的资源利用和性能。因此，当 pipe 仅用于发送通知而非数据传输时，应优先选择 eventfd/timerfd。

       eventfd/timerfd 与 epoll 结合使用时，可实现非阻塞的读取等特性，进一步提升性能。同时，这两个机制的设计使得它们与 epoll 的集成更加紧密，能够支持在监控其他文件描述符状态的同时，同时监控内核通知机制。这为应用程序提供了更高效和灵活的事件处理方式。

       在内核源码中，eventfd 的实现作为系统调用在 fs/eventfd.c 下实现在 2.6. 版本中引入，并在 2.6. 版本后增加了对 flag 的支持。其核心数据结构是 eventfd_ctx，包含一个 位计数器和其他相关组件。read 函数通过加锁实现对计数器的独占访问，并在阻塞或非阻塞模式下返回相应的结果。write 函数则同步更新计数器值并唤醒等待队列中的线程。poll 操作则用于监控 eventfd 的可读事件状态。

       总结而言，eventfd/timerfd 提供了高效和简单的事件通知机制，内核源码中实现了这些机制的精巧高效性。这些机制不仅功能实用，而且调用方式简单，为用户态应用程序封装了高效的事件通知机制，同时也与 epoll 等系统功能高度集成，提供了丰富的事件处理方式。

       参考资料：

       - Linux 内核源码：elixir.bootlin.com/linu...

       - Linux Programmer's Manual：eventfd(2) - Linux manual page