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).