The same document also states: Cancellation points are points inside of certain functions where a thread has to act on any pending cancellation request when cancelability is enabled. For functions in the "shall occur" list, a cancellation check must be performed on every call regardless of whether, absent the cancellation, the call would have blocked.
The phrase you mention has a clause "an event that a thread is waiting for has occurred", which implies the thread is effectively in a waiting state. It might have performed the cancellation check before that, and that's specifically allowed. But it must perform the check. What is not to be allowed is that a function that is defined as a cancellation point doesn't perform a check at all before returning. Because if that cancellation point is the only one, it may make the thread uncancellable depending on input on which the implementor may have no control over whatsoever. Having to perform a check on the result (that may or may not occur) and calling pthread_testcancel() is not a consistent API. In that case, it would be better to define the function as not being a cancellation point at all and then people would have to implement a check and a pthread_testcancel(). On 06/14/17 11:49, Alexander Terekhov wrote: > http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html#tag_22_02_09_24 > > "Due to the nature of cancellation, there is generally no > synchronization between the thread requesting the cancellation of a > blocked thread and events that may cause that thread to resume > execution. For this reason, and because excess serialization hurts > performance, when both an event that a thread is waiting for has > occurred and a cancellation request has been made and cancellation is > enabled, POSIX.1-2008 explicitly allows the implementation to choose > between returning from the blocking call or acting on the cancellation > request." > > I think that the above makes sense also for the events that happened > 'yesterday' (e.g. absolutely expired timeouts) when a' blocking call' > does not really 'block' in a metaphysical sense and only reports an > occurrence of an event. > > regards, > alexander. > > > > From: Dimitri Staessens <dimitri.staess...@ugent.be> > To: shwares...@aol.com, austin-group-l@opengroup.org > Date: 14.06.2017 08:33 > Subject: Re: request for clarification on Open Group Base > Specifications Issue 7: Canc... > ------------------------------------------------------------------------ > > > > On 06/14/17 01:18, _SHwareSyst@aol.com_ <mailto:shwares...@aol.com>wrote: > While that is the link for general consumption, it's also available at: > _https://www.opengroup.org/austin/login.html_ > along with other versions and support documents. > Thanks! > > As to the text, when a preemptive scheduler is being used there's a > remote chance an interface can perform the cancellation check on > entry and see none are pending, yet lose its time slice on the > statement after the check and be blocked that way. In normal use > this is the primary reason a thread will block, as the time slices will > be small in duration to give an appearance of parallelism. > An awakened thread can then issue a cancel request, but this does > not have to be processed by the blocked thread until the next > cancellation point after it's awakened again. This applies to all > interfaces in the "shall occur" list, and "may occur" one, along with > other reasons to block such as timers or waiting on a device for > read(), in how they're phrased. > I fully agree. But if the cancellation request was pending before the > call > to the cancellation point, cancellation points in the "shall occur" > list have > to check the cancellation prior to returning. I'll give it some > thought how > to phrase this with the least chance for misinterpretation. > They're not supposed to assume > threads block only for those secondary reasons, as occurs with a > non-preemptive scheduler that requires threads to use > sched_yield() to allow another thread to resume. > > Because of this an interface may block at least twice during the > same call to it, first due to losing time slice and then interface > specific reasons. With really small time slices the time needed > to release resources such as mutexes can cause additional time > slice expiration blocks after the interface specific block too. > > In a message dated 6/13/2017 11:51:50 A.M. Eastern Daylight Time, > _dimitri.staessens@ugent.be_ <mailto:dimitri.staess...@ugent.be>writes: > > Can someone confirm that this is the correct full version of the > specification to reference if I file a bug report? > > _http://ieeexplore.ieee.org/document/7582338/_ > > On 06/13/17 18:05, Dimitri Staessens wrote: > > So apparently this change was somehow intended to allow the case. But > it is nevertheless wrong since it contradicts the following statement: > > "For functions in the "shall occur" list, a cancellation check must be > performed on every call regardless of whether, absent the > cancellation, the call would have blocked." > > So even if there is a timeout, those functions have to check > cancellation and the behaviour is thus not undefined. The behaviour > may only be undefined if the cancellation point already performed the > check and is now suspended. > > I'd like to file a bug report and propose a change to the > specification to fix this. I'm new to this group and saw that the bug > reports reference page numbers. Can someone point me to where I can > find the official document so I can make the correct references? > > Thanks, > > Dimitri > > > On 06/13/17 15:13, Dimitri Staessens wrote: > Hi Geoff, > > Awesome service, thanks! > > Dimitri > > On 06/13/17 13:35, Geoff Clare wrote: > > Dimitri Staessens <dimitri.staess...@ugent.be> wrote, on 12 Jun 2017: > > Is there a way for me to track down the people that are responsible for > this adjustment in the specification so that they can comment on their > intentions and motivations for making it? > > _https://collaboration.opengroup.org/austin/interps/documents/14359/AI-136.txt_ > > > > > > >
