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 |
|