Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0000632 [1003.1(2008)/Issue 7] System Interfaces Editorial Clarification Requested 2012-11-09 13:29 2019-06-10 08:55
Reporter dalias View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Rich Felker
Organization musl libc
User Reference
Section XSH 2.9.5, pclose
Page Number unknown
Line Number unknown
Interp Status Approved
Final Accepted Text Note: 0001447
Summary 0000632: Side effects of pclose on cancellation are not specified
Description pclose is an optional cancellation point, but the text in XSH 2.9.5 regarding side effects on cancellation is insufficient to specify its behavior when cancelled, since pclose is explicitly documented not to return early ("In any case, pclose() shall not return before the child process created by popen() has terminated.") and thus not to fail with EINTR.
Desired Action Either remove pclose from the list of optional cancellation points, or add language specifying what actions are permitted by the implementation when pclose is cancelled. The most important question is whether the stream is closed or not; not closing it would allow the application to attempt to pclose again from its cancellation handlers. However at this point the pipe must already be closed, so the stream would already be non-functional for further use. Lesser issues, but still important, are whether it might leak a pid, kill the child, or continue waiting.
Tags tc2-2008
Attached Files

- Relationships
related to 0000529Appliedajosey fildes unspecified on close()'s [EINTR] 
related to 0000614Appliedajosey Behavior of close() as a cancellation point is unspecified 

-  Notes
(0001440)
ajosey (manager)
2013-01-10 16:09

 The minutes from 6 December 2012 recorded:

After a lengthy discussion we came to the conclusion that pclose()
and cancellation do not mix. We considered leaving the normative
text as-is and just adding application usage warning that applications
should not cancel a thread that is executing pclose(), but we felt
that was not strong enough. The direction we plan to take is for
the normative text to state that if a thread is cancelled while it
is executing pclose(), the behaviour is undefined.

This is being left open for feedback.
(0001447)
msbrown (manager)
2013-01-17 16:35

 Interpretation response
------------------------
The standard states pclose is an optional cancellation point, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor.

Rationale:
-------------
After a lengthy discussion we came to the conclusion that pclose()
and cancellation do not mix. We considered leaving the normative
text as-is and just adding application usage warning that applications
should not cancel a thread that is executing pclose(), but we felt
that was not strong enough. The direction we plan to take is for
the normative text to state that if a thread is cancelled while it
is executing pclose(), the behaviour is undefined.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
We recommend that the following text be placed on P1396 as a new paragraph after line 45712:
If a thread is canceled during execution of pclose(), the behavior is undefined.

We recommend that in Section XSH 2.9.5:

At page 513 line 17758 remove pclose() from the list of functions in which a cancellation point may occur.

At page 514 line 17795 append to the paragraph about EINTR:
For functions that are explicitly required not to return when interrupted (for example, pclose()), if a thread is canceled while executing the function, the behavior is undefined.
(0001518)
ajosey (manager)
2013-03-29 08:04

 Interpretation Proposed 29 Mar 2013
(0001578)
ajosey (manager)
2013-05-03 12:19

 Interpretation approved 3 May 2013

- Issue History
Date Modified Username Field Change
2012-11-09 13:29 dalias New Issue
2012-11-09 13:29 dalias Status New => Under Review
2012-11-09 13:29 dalias Assigned To => ajosey
2012-11-09 13:29 dalias Name => Rich Felker
2012-11-09 13:29 dalias Organization => musl libc
2012-11-09 13:29 dalias Section => XSH 2.9.5, pclose
2012-11-09 13:29 dalias Page Number => unknown
2012-11-09 13:29 dalias Line Number => unknown
2012-11-28 17:27 nick Relationship added related to 0000529
2012-11-28 17:37 nick Relationship added related to 0000614
2013-01-10 16:09 ajosey Note Added: 0001440
2013-01-17 16:35 msbrown Note Added: 0001447
2013-01-17 16:36 msbrown Interp Status => Pending
2013-01-17 16:36 msbrown Final Accepted Text => Note: 0001447
2013-01-17 16:36 msbrown Status Under Review => Interpretation Required
2013-01-17 16:36 msbrown Resolution Open => Accepted As Marked
2013-01-17 16:42 msbrown Tag Attached: tc2-2008
2013-03-29 08:04 ajosey Interp Status Pending => Proposed
2013-03-29 08:04 ajosey Note Added: 0001518
2013-05-03 12:19 ajosey Interp Status Proposed => Approved
2013-05-03 12:19 ajosey Note Added: 0001578
2019-06-10 08:55 agadmin Status Interpretation Required => Closed

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