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-13 09:29 UTC
====================================================================== 
Summary:                    pthread_sigmask() pending signal requirement time
paradox
====================================================================== 

---------------------------------------------------------------------- 
 (0006326) geoffclare (manager) - 2023-06-13 09:29
 https://austingroupbugs.net/view.php?id=1731#c6326 
---------------------------------------------------------------------- 
Re https://austingroupbugs.net/view.php?id=1731#c6325

> 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

You don't seem to have considered the case where the thread that receives
the signal is currently running, and is executing user code. Then there is
nothing to delay the delivery - it can happen immediately after generation,
if the signal is not being blocked; it only becomes pending if it is being
blocked.

Having said that, it would make sense to reword to avoid any subtle
distinctions about exactly when a signal becomes pending. I will try to
come up with something that merges parts of your suggestion with parts of
my previous attempt. 

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                          
2023-06-12 22:21 kre            Note Edited: 0006325                         
2023-06-13 09:09 dannyniu       Issue Monitored: dannyniu                    
2023-06-13 09:29 geoffclare     Note Added: 0006326                          
======================================================================


  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
    • Re: [10... Geoff Clare via austin-group-l at The Open Group
    • Re: [10... Robert Elz via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • Re: [1003.1(... Robert Elz via austin-group-l at The Open Group
    • Re: [10... G. Branden Robinson via austin-group-l at The Open Group
    • Re: [10... Robert Elz via austin-group-l at The Open Group
      • Re:... G. Branden Robinson via austin-group-l at The Open Group
      • Re:... Robert Elz via austin-group-l at The Open Group
    • Re: [10... Scott Lurndal via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to