On Fri, Apr 1, 2011 at 11:41 AM, Erik Faye-Lund <kusmabite@xxxxxxxxx> wrote: > On Thu, Mar 31, 2011 at 8:45 PM, Jeff King <peff@xxxxxxxx> wrote: >> We just need to cancel the thread, instead of sending it a >> signal as we do for fork()'d async sections. >> >> Signed-off-by: Jeff King <peff@xxxxxxxx> >> --- >> This could also just be part of the merge resolution, but I thought it >> would be easier to see what is going on if I put it here. >> >> run-command.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/run-command.c b/run-command.c >> index e31c073..46ea07d 100644 >> --- a/run-command.c >> +++ b/run-command.c >> @@ -607,7 +607,7 @@ void abort_async(struct async *async) >> #ifdef NO_PTHREADS > > This context-line doesn't match 3/4... Did you send out the wrong > version of that patch? > >> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html