At 2023-06-14T06:00:51+0700, Robert Elz via austin-group-l at The Open Group wrote: > Date: Tue, 13 Jun 2023 16:38:54 -0500 > From: "G. Branden Robinson via austin-group-l at The Open Group" > <austin-group-l@opengroup.org> > Message-ID: <20230613213854.hk3z6zzpkhdiunsk@illithid> > > | I apologize for the possibly academic recapitulation of multitasking, > | but the key point is that the foregoing model does not require the > | process to "enter the kernel" to service the signal. > > "enter" was perhaps a poor choice of words, for the general case, "be > in" might be better.
Okay. I prefer to think of user-space code as clients that are either
running or a kernel service (possibly a message passed from another user
thread)...but I've spent some time working with a microkernel so my
perspective may be a little unorthodox. :)
> But Geoff's message, to which I was replying, said:
>
> is currently running, and is executing user code.
>
> A process in that state was the one to which I was referring. Such
> a process must actually enter the kernel (since it is not there at the
> time) in order for the kernel to deliver a signal to it.
I think the foregoing would be a misleading characterization of the
preëmption model I described, but that doesn't have to concern POSIX.
[...]
> The issue was that even in that case, the signal is pending for some
> period (usually a very short period, perhaps just a few microseconds,
> but also possibly longer).
I agree that there is a finite time between the kernel electing, or
being directed to, preëmpt a user thread, and that preëmption taking
place.
[...]
> [when returning from a signal handler] - that's true in most cases, but
> not if the signal handler blocked signals as part of its invocation.
> In that case, some kind of call to the kernel is needed to return the
> signal mask to its state before the handler was invoked.
Yes--I elided too much context in my original reply.
> | I guess the question from the POSIX perspective is whether a
> | signal can be pending if a process cannot observe it to be.
>
> I don't think that matters. The notion is used as a mechanism to
> allow the existence of signals which do not get immediately delivered
> to the process.
No, you're right--I think your comment #6320 on Mantis captured the
practical importance of getting the wording right:
"Anything that arrives at the same time as the call is being processed
is just in a race to see which of those two cases it is considered
equivalent to."
I will recapitulate in an effort to verify my understanding (and perhaps
others').
1. Thread A calls pthread_sigmask to block SIGINT.
2. Something with permission to signal thread A calls kill(...,
SIGINT).
3. Thread A returns from pthread_sigmask.
The question is, did thread A receive SIGINT or not? It of course
depends. There is no guarantee that pthread_sigmask will run
atomically; it has to validate its parameters, it might be part of a
user-mode threading implementation (e.g., "green threads" or something
similar to the Ada tasking model [as long as it uses POSIX threads
underneath]). Moreover, pthread_sigmask does not impose a lock on the
rest of the system while it operates.
So just like hardware getting a spurious interrupt (by the time the CPU
goes to service the interrupt, the device has stopped asserting it), a
thread may receive a blocked signal in a small window of time "after"
calling pthread_sigmask() to block that very signal. Isn't this one of
the things that signal-masking programs simply have to be prepared for?
It looks to me like lines 44125-38 (under "kill" in XSH) in Issue 8
draft 2.1 address this issue. And the "RATIONALE" of pthread_sigmask()
already refers to it (line 59867).
Is the current draft language therefore redundant? Can lines 59787-8 be
deleted without damaging anything?
> The recent discussion has been entirely about how to write down the
> notion that a signal might be delivered to a process while it is
> executing the function that unblocks (other) signals.
Thanks for emphasizing the narrow scope. I've tried to direct my reply
accordingly.
> ps: SIGQUIT is not an "un-handleable signal" - the only signals that
> cannot be caught, are SIGKILL and SIGSTOP. There's nothing
> particularly special about SIGQUIT at all.
Yes, you are right; I had a brain fart that I really should not have had
given the number of times I've typed "trap ... HUP INT QUIT TERM" in
shell scripts.
Regards,
Branden
signature.asc
Description: PGP signature
