On Thu, Jun 13, 2024 at 10:21:39AM +0530, Dev Jain wrote: > I guess we agree on the same thing; so, how about I rephrase the delivery > and blocking code comments this way: > "A process can request blocking of a signal by masking it into its set of > blocked signals; such a signal, when sent to the process by the kernel, will > get blocked by the process and it may later unblock it and take an action. > At that point, the signal will be "delivered". Yes. > A signal sent by the kernel to the process, is said to be delivered to the > process when the process takes an action upon receipt of the signal: such > action may include termination, or jumping to a signal handler." I'd just drop this last paragraph. > > TBH I'm not sure what you mean there by real time signals, I can't see > > a reference to real time in the copies of signal(2), signal(7) or > > sigaction(2) on my system. I suspect SA_NODEFER is the actual thing > > here. > Real-time signals get a mention on signal(7), under the heading > "Real-time signals": Ah, it's got a - in there so it doesn't show up in searches. > > I still don't follow what the above means. When you say "invariant" you > > don't specify with respect to what, and it's not clear to me why the > > saved context in ucontext would have changed without the handler writing > > to it. For clarity I think this needs to say what the ucontext is > > expected to be the same as/different to. > The ucontext at this stage is supposed to be empty, I guess I'll replace > the word "invariant" then. > "it's not clear to me why the saved context in ucontext would have changed > without the handler writing to it" - by invariant I meant, the set of blocked > signals before invocation of handler is exactly the set of signals blocked in > ucontext, which, in this case, is the empty set. I'll just write that ucontext > is empty. Yes, or like I say in general it's the the interrupted context (there's other parts of the signal frame which are changed).
Attachment:
signature.asc
Description: PGP signature
