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-06-12 13:08 UTC ====================================================================== Summary: pthread_sigmask() pending signal requirement time paradox ======================================================================
---------------------------------------------------------------------- (0006320) kre (reporter) - 2023-06-12 13:08 https://austingroupbugs.net/view.php?id=1731#c6320 ---------------------------------------------------------------------- wrt https://austingroupbugs.net/view.php?id=1731#c6319 The substantive change looks fine to me - I have no problem with the "If the argument set is not a null pointer" qualification, as in that case (whether or not this function is implemented as a system call in that case) no pending signals can have been unblocked - if anything unblocked had been posted earlier, it would have already been delivered. Anything that arrives just after the call will be delivered when it arrives. 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. Beyond that, I'd have no objection if this function were to have this whole paragraph deleted, and not say anything about signal delivery - though it is probably better that it remain. [Note: we do not say in write() that if there are any pending unblocked signals when it is about to return, that they be delivered before write returns - but if the write caused a SIGPIPE that is what happens. It just doesn't need explicit mention there. It isn't really required here either - just this is a somewhat odd case, where it probably helps.] However, assuming that we really need that APPLICATION USAGE text at all, which I doubt, it needs a wording change. In particular, signals can become pending for reasons other than being blocked makes no sense, being blocked never makes a signal become pending. Being unblocked is what does that... I know what you intended to say (or at least I can guess), which would have been fine, but those words are not it. I suspect something more like In particular, signals may have become pending for reasons other than having previously been posted, but blocked, and unblocked by this call. The delivered signal(s) could be ones that just became pending during the <i>pthread_sigmask</i>() call. (something like that, perhaps a little briefer). 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 2023-05-25 18:32 kre Note Edited: 0006292 2023-05-25 18:44 kre Note Added: 0006293 2023-05-30 11:14 geoffclare Note Added: 0006294 2023-05-31 19:50 kre Note Added: 0006296 2023-06-06 15:50 geoffclare Note Added: 0006312 2023-06-06 19:24 kre Note Added: 0006313 2023-06-07 09:44 geoffclare Note Added: 0006314 2023-06-09 11:24 kre Note Added: 0006316 2023-06-12 08:55 geoffclare Note Added: 0006319 2023-06-12 09:08 geoffclare Note Edited: 0006319 2023-06-12 13:08 kre Note Added: 0006320 ======================================================================
