On Wed, 09 Nov 2022 16:47:22 +0000, Scott Cheloha wrote: > I think this could use some sprucing. > > NAME > > - "stop until signal" -> "wait for a signal" > > Feels more natural to me.
OK > DESCRIPTION > > - It's "the calling thread" that blocks, not "a process". > > - Nothing is "forced". > > - It "blocks", it doesn't "pause". Saying pause(3) "pauses" > is too circular. Block seems better to me too. Sleep would also work that may be less precise. > - No need to enumerate the ways a signal can be delivered. That is > better left to other manpages. Nix kill(2) and setitimer(2) from > the DESCRIPTION. > > - No need to mention that we don't return until the signal handler > returns either, that's just basic signal(3) stuff. OK. > - Should we explicitly mention the underlying implementation system > calls or not? I'm unsure. I don't think there is any reason to document the implementation details. > RETURN VALUES > > - Pull ERRORS into this section. No need to put the one error in a > .Bl/.El, we can just mention it inline. OK > SEE ALSO > > - Nix select(2) and setitimer(2), they aren't directly relevant. OK. The reason select(2) is there is probably because you can emulate pause() using select(). > - Add sigprocmask(2) and signal(3). They are very relevant. OK. > HISTORY > > - We still have sigpause(3) and sigblock(3) in userspace. Should > we .Xr them? They aren't systems calls anymore, but they were > at that time. Unsure what to do here. I think it is better to use .Fn for sigpause(3) and sigblock(3) rather than .Xr here. Note that in 4.3-Reno pause(3) was still implemented in terms of sigpause(3) and sigblock(3), it is just that those functions were themselves wrappers instead of system calls. Personally, I would drop the bit about 4.3-Reno since it is not really correct in my opinion. - todd
