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

---------------------------------------------------------------------- 
 (0006312) geoffclare (manager) - 2023-06-06 15:50
 https://austingroupbugs.net/view.php?id=1731#c6312 
---------------------------------------------------------------------- 
Re https://austingroupbugs.net/view.php?id=1731#c6296 I poked around in the
Illumos code on github and I think I
have found the equivalents of most of the code you examined for BSD
4.4_lite. There is a major difference that affects the behaviour we are
discussing. I won't post the code here as I know some people make a point
not to look at code with certain licences, but will give links and try to
describe what I'm seeing.

The sigprocmask() code is in
https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/syscall/sigprocmask.c

It calls lwp_sigmask() to do the signal mask change. The code in there is
very similar to the BSD sigprocmask() code, but in the switch it has a
difference in behaviour between the cases. For SIG_UNBLOCK and SIG_SETMASK
it has some code which sets the t_sig_check flag for the thread if a call
to sigcheck() returns true. It does not do this for SIG_BLOCK. The code for
sigcheck() is in
https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/os/sig.c
but everything you need to know about it is in the comment before the
function definition: "Return non-zero if curthread->t_sig_check should be
set to 1, that is, if there are any signals the thread might take on return
from the kernel."

The t_sig_check flag is used in the post_syscall() function in
https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/sparc/os/syscall.c

The code there only checks for pending signals if either t_astflag or
t_sig_check is set for the thread, and has this comment: "All code that
sets signals and makes ISSIG_PENDING evaluate true must set t_sig_check
afterwards."

Since t_sig_check isn't set by sigprocmask() when called with SIG_BLOCK, it
looks like Illumos might not conform to the requirement you are proposing. 

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


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

Reply via email to