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 22:18 UTC ====================================================================== Summary: pthread_sigmask() pending signal requirement time paradox ======================================================================
---------------------------------------------------------------------- (0006325) kre (reporter) - 2023-06-12 22:18 https://austingroupbugs.net/view.php?id=1731#c6325 ---------------------------------------------------------------------- wrt the updated https://austingroupbugs.net/view.php?id=1731#c6319 I'd simply delete the whole sentence starting "In particular..." and replace it with something more like It is possible that an unrelated signal (or signals) become pending [xref] during the period the pthread_setmask() call is executing. One (or more) of those signals may be delivered to the application instead of, or in addition to, any previously blocked pending signals that were unblocked by the pthread_setmask() call. Or something along those lines, but ideally briefer. The new wording "when a signal is generated it can become pending for reasons other than being blocked" is no better than the previous attempt, all signals become pending when generated (for a short while at least, sometimes very short) all being blocked does is prevent them from being delivered for longer (until they are unblocked) - but they are always pending from the instant they are generated, until the system has an opportunity to resume execution of the process (or thread) next - in the simplest case (a system call results in a signal being posted to the invoking process) that is at least for whatever time remains during the processing/cleanup of the system call in question. In other cases (a signal delivered to a process that is swapped out) the delay before it can be resumed can be considerable - that could even happen during a pthread_sigmask() call, if the scheduler decides to run a higher priority process instead of the caller, which is then blocked waiting upon a suitable CPU, and could get swapped out while it is waiting. Unlikely perhaps on modern systems, but on some ancient systems, that kind of thing happened all the time, and is still possible. 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 2023-06-12 13:13 kre Note Edited: 0006320 2023-06-12 14:38 geoffclare Note Edited: 0006319 2023-06-12 22:18 kre Note Added: 0006325 ======================================================================
