On 06/14/17 01:18, 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.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
>>>>
>>
>
