Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001142 [1003.1(2016)/Issue7+TC2] Base Definitions and Headers Editorial Omission 2017-06-03 23:42 2017-06-12 09:18
Reporter dancol View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Daniel Colascione
Organization
User Reference
Section 2.4.3 Signal Actions
Page Number
Line Number
Interp Status ---
Final Accepted Text
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 No tags attached.
Attached Files

- Relationships

-  Notes
(0003753)
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.
(0003754)
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().
(0003757)
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?
(0003759)
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.

- 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


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