A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1731 ====================================================================== Reported By: geoffclare Assigned To: ====================================================================== Project: 1003.1(2016/18)/Issue7+TC2 Issue ID: 1731 Category: System Interfaces Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: Geoff Clare Organization: The Open Group User Reference: Section: pthread_sigmask() Page Number: 1734 Line Number: 56243 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2023-05-23 09:43 UTC Last Modified: 2023-05-25 18:26 UTC ====================================================================== Summary: pthread_sigmask() pending signal requirement time paradox ======================================================================
---------------------------------------------------------------------- (0006292) kre (reporter) - 2023-05-25 18:26 https://austingroupbugs.net/view.php?id=1731#c6292 ---------------------------------------------------------------------- Re https://austingroupbugs.net/view.php?id=1731#c6288 There are two important general comments relevant here, before getting to the details of the specific issue: First: how people expect implementations to behave is not, or should not be, relevant here. What matters is how implementations do behave, not how someone would like them to. And even more important: Yes, there is a subtle difference in the new wording If that was intentional, and not just a poor choice of replacement text, then we have real problems. Attempting to insert changes in the way that the specification is written, via underhand mechanisms like that, is totally unacceptable. If the real reason for this defect report, is to make a change in the way that implementations are required to behave, then the description of the problem should have been clear about that - not just hiding things as if it were just some minor grammatical error that should be fixed, which was how it was presented. While the grammar of the current standard could be improved, to avoid the issue mentioned in the description, there is no real need to do so from the point of view of the standard itself. What is required is clear, only someone looking at it from a peculiar language perspective would even notice the problem. My "alternative suggestion" is simply restating what the standard currently says, in a way that avoids the problematic language. I'm sure there are other ways that would work as well, if you don't like my suggested wording. That is, which would work without changing the standard. As to how implementations work - it has been a while since I got down and dirty at the syscall interface, but the way all this used to work (and probably still does, since I cannot imagine much reason for changing it) is that signals cannot be delivered to an application while the kernel is currently executing code on behalf of the application (ie: when it is running the code of a system call). But signals can arrive during that period - either as a result of the system call itself, or simply by chance (sent from some other process, perhaps a child exiting causing SIGCHLD, or from another thread of this process perhaps). So the general method was, just as the system call is ending, and control is about to be returned to the user, the kernel checks to see if there are any pending unblocked signals - anything that would already have been delivered, had we not been in a system call. At this point, the code often barely knows (perhaps doesn't know at all) what system call is ending, and certainly has no idea what signals that are pending might have been generated or unmasked, by this system call. All it knows is that there is a pending signal, and that signal can now be delivered, so it is made to happen. Do you have some evidence that there are systems that behave differently than that, or do you just thing there ought to be? Issue History Date Modified Username Field Change ====================================================================== 2023-05-23 09:43 geoffclare New Issue 2023-05-23 09:43 geoffclare Name => Geoff Clare 2023-05-23 09:43 geoffclare Organization => The Open Group 2023-05-23 09:43 geoffclare Section => pthread_sigmask() 2023-05-23 09:43 geoffclare Page Number => 1734 2023-05-23 09:43 geoffclare Line Number => 56243 2023-05-23 09:43 geoffclare Interp Status => --- 2023-05-23 21:08 kre Note Added: 0006287 2023-05-25 08:40 geoffclare Note Added: 0006288 2023-05-25 18:26 kre Note Added: 0006292 ======================================================================
