Linux内核中为何进程限制被置于信号结构体内？

首先要明确两个内核侧的基础认知：

1. Linux对应用户态“进程”的实现，是一组拥有独立task_struct的内核实体组成的线程组，组内所有实体共享一批跨线程的状态；
2. signal_struct就是这组共享状态的核心载体——整个线程组仅存在一份该结构的实例，所有线程均可访问其内部字段。

将资源限制数组绑定在这个结构中，核心逻辑完全围绕工程实现的成本、性能和语义一致性展开：

• 共享粒度完全匹配，省去额外同步逻辑
  进程资源限制的生效范围是整个用户态进程，而非单个内核线程：任意一个线程通过setrlimit修改的资源上限，必须对同进程的所有线程可见、生效。signal_struct本身就是全线程组唯一持有、无需跨实体同步的共享结构，把rlim[RLIM_NLIMITS]放在这里，从存储层面就保证了全线程看到的限制值完全一致，不需要为了同步多份副本加锁、做内存拷贝，大幅降低了实现复杂度。
• 减少内存冗余，优化访问效率
  如果把rlimit数组放在每个独立的task_struct内部，一个拥有几十甚至上百个线程的进程，会重复存储上百份完全相同的资源限制值，平白造成内核内存浪费。而signal_struct在线程组维度仅存一份，加上rlimit数组和同属共享状态的挂起信号集合、信号处理函数表连续存储在同一块内存区域，内核查取rlimit值时不需要跨多个内存结构跳转，CPU缓存的命中率更高，访问延迟更低。
• 语义层面的自然适配
  绝大多数rlimit的触发逻辑，本身就和信号投递强绑定：比如进程达到CPU时间硬上限时，内核会给整个线程组投递SIGXCPU；进程突破地址空间上限时，内核会向触发越界的线程投递SIGSEGV。把rlimit放在信号结构内部，内核做触发校验时不需要跨结构查询当前进程的限制值，直接在同一块内存中就能完成判断，减少了函数调用的层级。

这种设计的本质，是将所有“需要对整个用户态进程生效、不需要单个线程独立维护”的状态，统一收拢到signal_struct中集中管理，从根源上避免了分散存储带来的一致性维护成本和内存冗余。

内容的提问来源于stack exchange，提问作者stepanov.dmit