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

---------------------------------------------------------------------- 
 (0006319) geoffclare (manager) - 2023-06-12 08:55
 https://austingroupbugs.net/view.php?id=1731#c6319 
---------------------------------------------------------------------- 
Here's an attempt at wording that uses "any pending unblocked signals" and
has no timing issues. I have kept the "<i>set</i> is not a null pointer"
condition from the desired action in order to be able to refer to the
signal mask change as a timing point. A side-effect of this is that if
pthread_sigmask() is used just to obtain the current mask, there is no
requirement on delivery of pending unblocked signals. This seems okay to me
as an implementation might be able to satisfy an enquiry for the current
mask without making a system call.

After applying bug 1636, change:<blockquote>If there are any pending
unblocked signals after the call to <i>pthread_sigmask</i>(), at least one
of those signals shall be delivered before the call to
<i>pthread_sigmask</i>() returns.</blockquote>to:<blockquote>If the
argument <i>set</i> is not a null pointer, after <i>pthread_sigmask</i>()
changes the currently blocked set of signals it shall determine whether
there are any pending unblocked signals; if there are any, then at least
one of those signals shall be delivered before the call to
<i>pthread_sigmask</i>() returns.</blockquote> 

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                          
======================================================================


  • [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
  • [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

Reply via email to