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
