A NOTE has been added to this issue. 
====================================================================== 
https://austingroupbugs.net/view.php?id=1832 
====================================================================== 
Reported By:                alanc
Assigned To:                
====================================================================== 
Project:                    Issue 8 drafts
Issue ID:                   1832
Category:                   System Interfaces
Type:                       Enhancement Request
Severity:                   Comment
Priority:                   normal
Status:                     New
Name:                       Alan Coopersmith 
Organization:                
User Reference:              
Section:                    System Interfaces 
Page Number:                (page or range of pages) 
Line Number:                (Line or range of lines) 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2024-05-24 21:48 UTC
Last Modified:              2024-05-26 02:43 UTC
====================================================================== 
Summary:                    Add preadv() and pwritev()
====================================================================== 

---------------------------------------------------------------------- 
 (0006805) Guy Harris (reporter) - 2024-05-26 02:43
 https://austingroupbugs.net/view.php?id=1832#c6805 
---------------------------------------------------------------------- 
> and even to have a future direction that they be forbidden from being
cancellation points.

Given that macOS has both "preadv" and "preadv_nocancel" system calls, and
that the GNU libc used in most Linux systems has both "preadv()" and
"__preadv_nocancel()" routines, it's likely that "preadv()" is a
cancellation point on both those OSes, so that might cause problems.

Furthermore, on both those OSes (and most if not all other UN*Xes), "slow"
operation scan occur on special files other than ttys, *and* those special
files might use the seek offset, so there might well be cases where making
pthreadv() not a cancellation point would cause problems, even if it
doesn't cause problems for POSIX-conformant programs.

So I would recommend against that.  Instead, if there is a demand for
non-cancellation-point calls, I would recommend, for a future direction,
that _nocancel versions of calls be added. I don't know why neither macOS
nor GNU(libc)/Linux provide _nocanncel versions of those APIs, but, other
than the namespace pollution issues, it would be trivial to provide them,
at least in those OSes. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2024-05-24 21:48 alanc          New Issue                                    
2024-05-24 21:48 alanc          Name                      => Alan Coopersmith
2024-05-24 21:48 alanc          Section                   => System Interfaces
2024-05-24 21:48 alanc          Page Number               => (page or range of
pages)
2024-05-24 21:48 alanc          Line Number               => (Line or range of
lines)
2024-05-24 21:56 Guy Harris     Note Added: 0006800                          
2024-05-25 23:10 alanc          Note Added: 0006803                          
2024-05-26 00:03 philip-guentherNote Added: 0006804                          
2024-05-26 02:43 Guy Harris     Note Added: 0006805                          
======================================================================


  • [Issue 8 dra... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to