pthread_cancel() alternatives in Android NDK?

Question

I am porting a mid-sized body of C++ code to Android NDK. Unfortunately the pthreads implementation (as of NDK v5, anyway) is incomplete. Specifically, our application relies on pthread_cancel() to kill a worker thread. NDK does not implement pthread_cancel()! There are other obvious answers when the worker thread is responding normally. But in cases where the worker thread is not responding (e.g. infinite loop), how can I cancel it without killing the whole process?

Solution

Possible option that works for this guy: http://igourd.blogspot.com/2009/05/work-around-on-pthreadcancel-for.html

Reposting here in case:

Then I use pthread_kill to trigger a SIG_USR1 signal and use signal handler to exit this pthread and tried it, it works, but still wondering if any drawbacks for this kind of method.

Timer out:

if ( (status = pthread_kill(pthread_id, SIGUSR1)) != 0) 
{ 
    printf("Error cancelling thread %d, error = %d (%s)", pthread_id, status, strerror status));
} 

USR1 handler:

struct sigaction actions;
memset(&actions, 0, sizeof(actions)); 
sigemptyset(&actions.sa_mask);
actions.sa_flags = 0; 
actions.sa_handler = thread_exit_handler;
rc = sigaction(SIGUSR1,&actions,NULL);
void thread_exit_handler(int sig)
{ 
    printf("this signal is %d \n", sig);
    pthread_exit(0);
}

Looks like the best answer is to rewrite so that threads aren't waiting on IO: http://groups.google.com/group/android-platform/browse_thread/thread/0aad393da2da65b1

Comments

[Chuck Fry]

The worker thread waits on a semaphore for external events when it waits, so that's the obvious place to add a check for thread cancellation. There is some limited blocking I/O but that's not the expected cause of the thread becoming unresponsive. I was hoping to avoid using signals for thread shutdown because that requires hacking sigmasks in every thread, IME.

[Jobayer Ahmed Mickey]

Yes it is a shame that is not in the current Android NDK, adds some annoying tasks. The joys of multi-platform development. We ported pretty easily our threading library as we don't have to use pthread_cancel or semaphores, but looks like some sort of rewrite/interface implementation will have to change due to that missing.

[jilles]

Calling pthread_exit() in a signal handler is basically what asynchronous cancellation does (see pthread_setcanceltype()). This is dangerous and hard to use correctly. Deferred cancellation is easier to use correctly as it only cancels at specific cancellation points (although it is still considerable effort), but it is also harder to implement for the threading library.

[Chuck Fry]

This suggestion is essentially what I implemented. I do wish there was a better solution, because signal handling is tricky to implement correctly. But this works and it's portable.

[Jobayer Ahmed Mickey]

pthreads are awesome, but aren't always pretty. Glad you got past it.

[Grimmace]

A cancel signal was considered when designing pthread_cancel(). The man page for pthread_cancel() describes the rational behind their choice: "Two alternative functions were considered for sending the cancellation notification to a thread. One would be to define a new SIGCANCEL signal that had the cancellation semantics when delivered; the other was to define the new pthread_cancel() function, which would trigger the cancellation semantics." For more details on why they picked their choice, see the man page.