关于sigaction重复传递信号ID的设计合理性疑问

其实这个重复传递真不是设计失误，而是有几个很实际的考量在里面，我来给你掰扯清楚：

• 历史兼容性与演进遗留：sigaction是从早期的信号机制（比如老式的signal函数）一步步演进过来的。早期的signal处理函数只接收一个信号ID参数，很多开发者已经习惯了这种直接的用法。sigaction推出时既要提供更完整的上下文信息，又不想让老代码迁移成本太高——所以保留了第一个参数的信号ID，让习惯旧接口的人能直接用；同时把信号ID也放进上下文结构里，保证这个上下文是自包含的完整现场，不需要依赖外部参数就能还原触发场景。

• 处理函数共享的灵活性：如果你把同一个处理函数注册给多个信号使用，第一个参数的信号ID能让你快速判断是哪个信号触发的，用起来很顺手。但有时候你需要结合上下文里的其他信息（比如当时的寄存器状态、关联的错误码等），这时候上下文里的信号ID是和这些现场数据绑定在一起的，确保你拿到的是对应这个特定现场的准确信号标识——它是上下文数据的必要组成部分，保证了结构的完整性，哪怕你不依赖第一个参数，也能从上下文里获取所有触发相关的核心信息。

• 内核实现的便利性：从操作系统内核的角度看，当信号触发时，内核必须构造一个包含所有现场信息的上下文结构，信号ID作为触发这个事件的核心标识，自然要被包含进去。而把它再单独作为第一个参数传递，其实是内核在构造完上下文之后顺手就能完成的操作，完全不需要额外的复杂逻辑去“刻意省略”。这种设计也给内核留了扩展空间，未来如果有需要，上下文里的信号字段可能携带更多扩展属性（不过目前和第一个参数是完全一致的）。

总的来说，这看起来的“冗余”其实是兼顾了易用性、兼容性和设计完整性的权衡结果，是有意为之的合理设计。

内容来源于stack exchange