流程解读
Puma 进程（可以有一个或多个）通过 Reactor类中的线程来接受来自套接字的连接。连接一旦完全缓冲并读取，就会移到 todo 列表中，可用的线程会从那里拾取它
在集群模式下，首先启动一个 master 进程，它会准备应用程序，然后使用 fork() 系统调用创建一个或多个 child 进程。这些 child 进程都监听同一个套接字。master 进程不监听套接字或处理请求，它的主要目的是管理和监听 UNIX 信号，并可能kill或启动 child 进程。
我们有时将 child 进程（或单进程模式下的 Puma 进程）称为 worker，有时将 Puma 的 ThreadPool:创建的线程称为 worker 线程。
启动时，Puma 会监听一个 TCP 或 UNIX 套接字。
该套接字的 backlog 默认配置为 1024，但实际的 backlog 值会受到 net.core.somaxconn sysctl 值的限制。
backlog 决定了未接受连接的队列大小。如果 backlog 已满，操作系统将不会接受新的连接。
当至少有一个 worker 线程可用于工作时，reactor 线程会监听套接字并接受请求（如果有等待的请求）。
- reactor 线程会等待整个 HTTP 请求接收完成。
- Puma 会将等待接收 HTTP 请求体所花费的时间以毫秒为单位暴露给 Rack 应用，作为 env['puma.request_body_wait']。
- 一旦完全缓冲并接收，连接就会被推送到 "todo" 集合中。
- worker 线程从 "todo" 集合中弹出工作进行处理。
- worker 线程通过调用配置的 Rack 应用来处理请求。Rack 应用生成 HTTP 响应。
- worker 线程将响应写入到连接。虽然 Puma 通过单独的线程缓冲请求，但它不会为响应使用单独的线程。
- 完成之后，线程变为可用，可以处理 "todo" 集合中的另一个连接。
源码解读
cli里初始化Launcher并调用#run方法
Launcher#run里调用runner(cluster)的run
Cluster#run调用 #spawn_workers启动进程
启动配置workers数量 - 已启动workers数量(工作进程)
spawn_workers方法在cluster的run方法内循环调用
cluster的spawn_worker继续调用worker方法，初始化worker(这里fork进程执行)并执行run
worker方法里start_server启动server，并给到worker
worker run方法里处理一些信号量；主要是启动了server.run
start_server获取到binder(io，如socket和tcp_listener等)
server.run 方法，启动线程池；
调用server.handle_servers，开始io多路复用(select)
这里我们先记住，同时启动了 清理空闲线程
使用client 并放入线程池
thread_pool里 << 把任务放入@todo里(使用mutex等保证线程安全)，且 线程未创建满时(小于最大数量)，再起新线程(span_thread)
spawn_thread后线程内
while true 无限循环，从todo里取出work，并执行block.call(work)
block是创建时传入的process_client
process_client又调用
handle_request，handle_request里最终出现了我们熟悉的@app.call
process_client会接着调用prepare_response -> fast_write_response 最终往io里写入了http response，整个流程完成
自动清理空闲线程
循环中遇到 todo为空，且有空闲线程清理标识，结束当前线程
