Take the 2-minute tour ×

in my Cocoa project, I communicate with a device connected to a serial port. Now, I am waiting for the serial device to send a particular message of some bytes. For the read operation (and the reaction for once the desired message has been received), I created a new thread. On user request, I want to be able to cancel the thread.

As Apple suggests in the docs, I added a flag to the thread dictionary, periodically check if the flag has been set and if so, call [NSThread exit]. This works fine.

Now, the thread may be stuck waiting for the serial device to finally send the 12 byte message. The read call looks like this:

numBytes = read(fileDescriptor, buffer, 12);

Once the thread starts reading from the device, but no data comes in, I can set the flag to tell the thread to finish, but the thread is not going to read the flag unless it finally received at least 12 bytes of data and continues processing.

Is there a way to kill a thread that currently performs a read operation on a serial device?

Edit for clarification: I do not insist in creating a separate thread for the I/O operations with the serial device. If there is a way to encapsulate the operations such that I am able to "kill" them if the user presses a cancel button, I am perfectly happy. I am developing a Cocoa application for desktop Mac OS X, so no restrictions regarding mobile devices and their capabilities apply. A workaround would be to make the read function return immediately if there are no bytes to read. How can I do this?

share|improve this question
add comment

2 Answers

up vote 2 down vote accepted

Use select or poll with a timeout to detect when the descriptor is ready for reading.

Set the timeout to (say) half a second and call it in a loop while checking to see if your thread should exit.

Asynchronous thread cancellation is almost always a bad idea. Try to stick with event-driven interfaces (and, if necessary, timeouts).

share|improve this answer
This is a very bad approach. You should never write applications that constantly wake up and poll a variable. This destroys battery life, and it sounds like OP is writing this for a mobile device, making that a big issue... You could achieve the same result eliminating the timeout/wakeups by adding a pipe to your select/poll call, and sending the abort request over the pipe. –  R.. Aug 28 '11 at 2:52
I am developing for desktop Mac OS X, so no mobile device restrictions. –  Björn Marschollek Aug 28 '11 at 7:10
add comment

This is exactly what the pthread_cancel interface was designed for. You'll want to wrap the block with read in pthread_cleanup_push and pthread_cleanup_pop in order that you can safely clean up if the thread is cancelled, and also disable cancellation (with pthread_setcancelstate) in other code that runs in this thread that you don't want to be cancellable. This can be a pain if proper cleanup would involve multiple call frames; it essentially forces you to use pthread_cleanup_push at every call level and structure your thread code like C++ or Java with try/catch style exception handling.

An alternative approach would be to install a signal handler for an otherwise-unused signal (like SIGUSR1 or one of the realtime signals) without the SA_RESTART flag, so that it interrupts syscalls with EINTR. The signal handler itself can be a complete no-op; the only purpose of it is to interrupt things. Then you can use pthread_kill to interrupt the read (or any other syscall) in a particular thread. This has the advantage that you don't have to switch your code to using C++/Java-type idioms. You can handle the EINTR error by checking a flag (indicating whether the thread was requested to abort) and resume the read if the flag is not set, or return an error code that causes the caller to clean up and eventually pthread_exit.

If you do use interrupting signal handlers, make sure all your syscalls that can return EINTR are wrapped in loops that retry (or check the abort flag and optionally retry) on EINTR. Otherwise things can break badly.

share|improve this answer
This is a very, very bad approach. Using a signal and EINTR creates an unavoidable race condition, because the signal might be delivered just before the thread enters read(). As a result, the read will not be interrupted and will block forever, but only when the race condition triggers... Making the bug extremely hard to reproduce and fix. Polling is approximately infinitely preferable. (That said, I agree the best answer is to add a pipe to the select/poll.) –  Nemo Aug 28 '11 at 2:57
In such an interactive use as OP wanted, the "block forever" would really be "block until the user presses the cancel button again". I agree there's a race condition here, which may be nontrivial to fix. For the general case, I can think of a complex framework with a nontrivial signal handler and longjmps out of signal handlers that could meet the requirements without making any async-signal-safety violations or other UB, but it's probably not what OP wants... –  R.. Aug 28 '11 at 4:32
add comment

Your Answer


