|Anonymous | Login||2020-08-04 08:11 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|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||2019-11-05 12:01|
|Section||2.4.3 Signal Actions|
|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.|
|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.|
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().
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?
|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.|
|The weekly teleconferences have reached bug 1118, so a little way to go yet before this one gets its turn.|
|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|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|