From: Johannes Sixt <j6t@kdbg.org>
Date: Fri, 01 Apr 2011 17:27:03 GMT
Subject: Re: [PATCH 5/4] run-command: implement abort_async for pthreads
Message-ID: <201104011927.03366.j6t@kdbg.org>
In-Reply-To: <AANLkTin3+PzYcQEaaxgr9_5mgDGO5oiYDyBD_2tJqCTk@mail.gmail.com>

On Freitag, 1. April 2011, Erik Faye-Lund wrote:
> On Fri, Apr 1, 2011 at 11:41 AM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> > On Thu, Mar 31, 2011 at 8:45 PM, Jeff King <peff@peff.net> wrote:
> >>        kill(async->pid, 15);
> >>  #else
> >> -       /* no clue */
> >> +       pthread_cancel(async->tid);
> >
> > My worry about terminating a thread that's currently holding a mutex
> > (implicitly through the CRT?) still applies though...
>
> OK, I've read up on thread-cancellation, and this code seems correct.
> pthread_cancel doesn't kill the thread right away, it just signals a
> cancellation-event, which is checked for at certain
> cancellation-points. A lot of the CRT functions are defined as
> cancellation points, so it'll be a matter for us Win32-guys to
> implement pthread_testcancel() and inject that into the
> function-wrappers of the CRT functions that are marked as
> cancellation-points.

That's not going to happen. We cannot implement pthread_cancel() on Windows 
because it would have to be able to interrupt blocking system calls. 
(TerminateThread() is a no-no, given all the caveats about leaking system 
resources that are mentioned in the manual.)

[OK, "cannot" is a hard word. It is possible in some way, I'm sure. But that 
would mean that we implement the equivalent of Cygwin or so...]

But if I understand correctly what Jeff wrote so far, then the pthreaded case 
happens to work - by chance or by design, we don't know (yet). Perhaps we can 
get away with

-	/* no clue */
+	/* pthread_cancel(async->tid); not necessary */

-- Hannes