Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001142 [1003.1(2016/18)/Issue7+TC2] Base Definitions and Headers Editorial Omission 2017-06-03 23:42 2024-06-11 09:09
Reporter dancol View Status public  
Assigned To
Priority normal Resolution Accepted  
Status Closed  
Name Daniel Colascione
User Reference
Section 2.4.3 Signal Actions
Page Number
Line Number
Interp Status ---
Final Accepted Text See Desired Action
Summary 0001142: pread(2) and pwrite(2) should be async-signal-safe
Description Shouldn't pread(2) and pwrite(2) be, by analogy to read(2) and write(2), be marked as async-signal-safe? Without these facilities being available to signal handlers, concurrent IO (say, between two different signal handlers running concurrently in different threads) requires explicit synchronization (so as to avoid disturbing the file pointer via lseek(2)). This synchronization is itself awkward given only the set of primitives available in the async-signal-safety list.
Desired Action Add pread and pwrite to the list of async-signal-safe functions in section 2.4.3.
Tags tc3-2008
Attached Files

- Relationships

-  Notes
shware_systems (reporter)
2017-06-06 12:14

While this looks reasonable, the restriction on pread() and pwrite() of not disturbing the seek position is problematic. It means an effective dup();lseek();read() or write();close() sequence occurs on each invoke. While each of these operations is supposed to be asynch-safe, how they're combined, or implemented otherwise internally, may not be; so requiring this could break existing implementations. If the routines use malloc() to get space for temporary descriptors or buffers, as example, this would make the entire routine unsafe, since malloc() is also not in the safe list.
geoffclare (manager)
2017-06-06 13:48

The standard already requires pread() and pwrite() to be async-signal-safe. The fact that they are missing from the list in 2.4.3 is simply an editorial omission (and Daniel correctly classified this bug as such).

This is because the description of pread() says "The pread() function shall be equivalent to read(), except that it shall read from a given position in the file without changing the file offset."

In order for pread() not to be required to be async-signal-safe, the standard would instead have to say "The pread() function shall be equivalent to read(), except that it shall read from a given position in the file without changing the file offset and it need not be async-signal-safe."

Likewise for pwrite().
dancol (reporter)
2017-06-10 02:13

shware_systems, in practice, pread and pwrite are direct system calls, so there are no particular userspace constraints preventing trivially (by definition) making these calls async-signal-safe.

geoffclare, do you plan to change the standard to fix this omission? Is there anything you need me to do?
geoffclare (manager)
2017-06-12 09:18

dancol, when this bug is reached in the weekly teleconferences, I expect that your proposed change will be accepted. There is nothing more you need to do.
dancol (reporter)
2018-07-24 17:53

geoffclare (manager)
2018-07-25 08:44

The weekly teleconferences have reached bug 1118, so a little way to go yet before this one gets its turn.

- Issue History
Date Modified Username Field Change
2017-06-03 23:42 dancol New Issue
2017-06-03 23:42 dancol Name => Daniel Colascione
2017-06-03 23:42 dancol Section => 2.4.3 Signal Actions
2017-06-06 12:14 shware_systems Note Added: 0003753
2017-06-06 13:48 geoffclare Note Added: 0003754
2017-06-10 02:13 dancol Note Added: 0003757
2017-06-12 09:18 geoffclare Note Added: 0003759
2018-07-24 17:53 dancol Note Added: 0004059
2018-07-25 08:44 geoffclare Note Added: 0004060
2018-10-25 16:25 nick Interp Status => ---
2018-10-25 16:25 nick Final Accepted Text => See Desired Action
2018-10-25 16:25 nick Status New => Resolved
2018-10-25 16:25 nick Resolution Open => Accepted
2018-10-25 16:25 nick Tag Attached: tc3-2008
2019-11-05 12:01 geoffclare Status Resolved => Applied
2024-06-11 09:09 agadmin Status Applied => Closed

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker