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-07 09:44 UTC ====================================================================== Summary: pthread_sigmask() pending signal requirement time paradox ======================================================================
---------------------------------------------------------------------- (0006314) geoffclare (manager) - 2023-06-07 09:44 https://austingroupbugs.net/view.php?id=1731#c6314 ---------------------------------------------------------------------- Re https://austingroupbugs.net/view.php?id=1731#c6313 I should have waited before posting my previous comment, as I woke up in the night thinking much the same as what you have pointed out. The t_sig_check flag must be getting set somehow when a signal is generated during any one of the many system calls that don't change the mask, and that mechanism would take care of the SIG_BLOCK case for pthread_sigmask/sigprocmask. You suggested looking at the kill() system call, but I couldn't find that (there is no kill.c in the same directory as sigprocmask.c). However, there are various places in the sig.c file (that contains sigcheck() - see link in my previous note) which could be doing it. E.g. eat_signal() sets it, and that is called from sigtoproc() which has the comment "Post a signal. If a non-null thread pointer is passed, then post the signal to the thread/lwp, otherwise post the signal to the process." Anyway, you have convinced me that my alternative wording suggestion in the desired action is wrong and the standard should stick with saying "any pending unblocked signals". Unfortunately, your suggested wording has a different time-related problem: Before the pthread_sigmask() call returns, if there are any pending unblocked signals, at least one of those shall be delivered. Taking your example of there being a SIGINT and SIGTSTP that both qualify as a "pending unblocked signal", suppose pthread_sigmask() identifies those two and chooses to deliver the SIGTSTP before returning. Let's examine the new situation immediately after this delivery: Is "before the pthread_sigmask() call returns" true? Yes. Is "there are any pending unblocked signals" true? Yes (SIGINT is). Your wording now requires that the SIGINT is delivered before pthread_sigmask() returns. Extrapolating, it effectively would require that all pending unblocked signals are delivered before pthread_sigmask() returns. I think finding some wording that doesn't have a timing issue is not going to be simple. 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 ======================================================================
