在文件 chassis-event-thread.c 中可以看到，通过 pipe 实现了向工作线程通知：在全局 event-queue 中有东东需要处理。从函数 chassis_event_handle() 可以看出，所有处于 idle 状态的线程都有平等机会进行事件处理，所以这些线程就能够“并行的”从全局事件队列中拉取 event ，并将其添加到自身的监听事件列表中。
通过调用 chassis_event_add() 或者 chassis_event_add_local() 函数可以将 event 添加到 event-queue 中。一般情况下，所有事件都由全局 event_base 负责处理。只有在使用 connection pool 的情况下，才会强制将与特定 server connection 对应的 events 投递到特定线程，即将当前 connection 加入到 connection pool 中的那个线程。
如果 event 被投递到全局 event_base 中，那么不同的线程都可以获取这个事件，并可以对无保护的 connection pool 数据结构进行修改，可能会导致竞争冒险和崩溃。令这个内部数据结构成为具有线程安全性质是 0.9 release 版本的工作，当前只提供了最小限度的线程安全性。
典型情况是，某个线程会从 event queue 中获取 request 信息(理论上，发送 wait request 的线程很可能也是处理这个 request 的线程)，并将其添加到自身以 thread-local-store 方式保存的 event_base 中，并在对应 fd 有事件触发时获得通知。
该处理过程将一直持续到当前 connection 被 client 或者 server 关闭，或者发生了导致的 socket 关闭的网络错误。此后将无法处理任何新的 request 。
单独一个线程就足以处理任何添加到其 thread-local 的 event_base 上面的 event 。只有在一个新的 blocking I/O 操作发生时(一般来说也就是重新进入 event_base_dispatch() 阻塞时)，event 才会在不同线程间被“跳跃着”处理，除此外没有其他例外。所以理论上讲，可能会出现一个线程处理了所有活跃的 socket 事件，而另一个线程一直处于 idle 状态。
然而，由于等待网络事件的发生的状态是常态(意思就是实际处理的速度都很快)，所以(从概率上讲)活跃 connection 在所有线程中的分布必定是很均匀的，也就会减轻单个线程处理活跃 connection 的压力。
值得注意的是，尽管在下面的说明中没有具体指出，主线程当前会在 accept 状态后参与到对后续 event 的处理中。这不是一个非常理想的实现方式，因为所有 accept 动作本身就需要在主线程中完成。但从另一方面讲，这个问题暂时也没成为实际工作中的瓶颈显现出来：
涉及到的实体：Plugin, MainThread, MainThreadEventBase, EventRequestQueue, WorkerThread1, WorkerThread1EventBase, WorkerThread2, WorkerThread2EventBase;
