[PATCH 08/11] Cygwin: testsuite: Busy-wait in cancel3 and cancel5

[Corinna Vinschen]

On Jul 13 20:16, Corinna Vinschen wrote:
> On Jul 13 12:39, Jon Turney wrote:
> > These tests async thread cancellation of a thread that doesn't have any
> > cancellation points.
> > 
> > Unfortunately, since 450f557f the async cancellation silently fails when
> > the thread is inside the kernel function Sleep(), so it just exits
> 
> I'm not sure how this patch should be the actual culprit.  It only
> handles thread priorities, not thread cancellation.  Isn't this rather
> 2b165a453ea7b or some such?
> 
> > normally after 10 seconds. (See the commentary in pthread::cancel() in
> > thread.cc, where it checks if the target thread is inside the kernel,
> > and silently converts the cancellation into a deferred one)
> 
> Nevertheless, I think this is ok to do.  The description of pthread_cancel
> contains this:
> 
>   Asynchronous cancelability means that the thread can be canceled at
>   any time (usually immediately, but the system does not guarantee this).
> 
> And
> 
>   The above steps happen asynchronously with respect to the
>   pthread_cancel() call; the return status of pthread_cancel() merely
>   informs the caller whether the cancellation request was successfully
>   queued.
> 
> So any assumption *when* the cancallation takes place is may be wrong.

I wonder, though, if we can't come up with a better solution than just
waiting for the next cancellation point.

No solution comes to mind if the user code calls a Win32 function, but
maybe _sigbe could check if the thread's cancel_event is set?  It's all
in assembler, that complicates it a bit, but that would make it at least
working for POSIX functions which are no cancellation points.


Corinna