A NOTE has been added to this issue. ====================================================================== http://austingroupbugs.net/view.php?id=1143 ====================================================================== Reported By: dstaesse Assigned To: ====================================================================== Project: 1003.1(2016)/Issue7+TC2 Issue ID: 1143 Category: Base Definitions and Headers Type: Clarification Requested Severity: Comment Priority: normal Status: New Name: Dimitri Staessens Organization: User Reference: Section: 2.9.5 Page Number: 520 Line Number: 18219-18223 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2017-06-14 13:59 UTC Last Modified: 2017-06-20 10:31 UTC ====================================================================== Summary: cancellation points: contradiction between base definition and rationale ======================================================================
---------------------------------------------------------------------- (0003793) dstaesse (reporter) - 2017-06-20 10:31 http://austingroupbugs.net/view.php?id=1143#c3793 ---------------------------------------------------------------------- That's an interesting reference. I think the phrase "A cancellation point will also occur in the following functions if the function causes the thread to block:" is not correct when applied to the current specification. It was correct when there was a clause that cancellation would only occur when the cancellation point blocks indefinitely. So indeed, a statement that these functions may cancel the thread if they are implemented using a cancellation point from the "shall occur" list is a very useful clarification to add. If they are implemented using a cancellation point, disabling the cancellation state might lead to hanging threads, so I wouldn't support removing them as possible cancellation points. It looks to me that, at some point, there was a choice to prioritise cancellation (and actually enforce it) over returning and continuing the thread execution. (Is there an easy way to go through the revision history to pinpoint that change?) Issue History Date Modified Username Field Change ====================================================================== 2017-06-14 13:59 dstaesse New Issue 2017-06-14 13:59 dstaesse Name => Dimitri Staessens 2017-06-14 13:59 dstaesse Section => 2.9.5 2017-06-14 13:59 dstaesse Page Number => 520 2017-06-14 13:59 dstaesse Line Number => 18219-18223 2017-06-14 14:25 terekhov Note Added: 0003760 2017-06-15 18:49 dstaesse Note Added: 0003765 2017-06-17 12:17 dstaesse Note Added: 0003783 2017-06-19 09:04 terekhov Note Added: 0003784 2017-06-20 03:50 dstaesse Note Added: 0003790 2017-06-20 09:59 terekhov Note Added: 0003792 2017-06-20 10:31 dstaesse Note Added: 0003793 ======================================================================
