Page History

...

In NuttX, thread or tasks may be canceled using pthread_cancle() or task_delete() These can also be cancel canceled via certain signals if default signal actions are enabled.

When threads or tasks are canceled asynchronously, resources may be stranded.  For example, if memory is allocated, it will not be deallocated when the task/thread is canceled in the FLAT build.  These kind on leaks can be handled by the application with functions registered with pthread_cleanup() or on_exit(), but others cannot.

The generic solution for NuttX is through the use of cancellation points.  Cancellation points are a mechanism that assures that all resources used internal by OS interface calls are cleaned-up automatically at designated cancellation points. An interface is normally a cancellation point if it has any possibility of blocking.

...

Corollary:  If cancellation points are enabled, the default cancellation mode should be deferred mode.

NOTE:  There are three interfaces affected by this issue: nxsem_wait_uninterruptible() as discussed above, but also nxsem_timedwait_uninterruptible() and nxsem_tickwait_uninteruptible() which are closely related.

Mutual Exclusion Semaphores vs. Signaling Semaphores

...

Should we return -ECANCEL/-EINTR for both?  Or only for ithe second?  I think both should work the same:  For both the semaphore wait should be terminated and correct error should be returned.

...

And even if taking the mutual exclusion semaphore does cause the thread to block, it should block form for only a very brief moment of time and the likelihood of a signal received or of the task being canceled is very small.

...

But the ECANCELED error is ABSOLUTELY critical to return under any circumstance.  That cancellation notification is received only once and it if is ignored, then the thread will not cancel it will continue to run. It really must return immediately with ECANCELED for the cancellation to work quickly and reliably, where ever ECANCELED is detected.  Ignoring it is a hard bug in any case.

The signaling semaphores are a little different story. The They may block for a very long time, for example, waiting for the receipt of data that will never come. For example, a read from a serial port will hang indefinitely if nothing is received on the serial port.  So if a signal is received or if the thread is canceled, then it is essential to terminate the semaphore wait and return the error condition.  We should have no difference of opinion on that.

...

However, if a signal is received while the OS interface is NOT waiting, then there is no way to know if the signal was received.  I think that is a limitation in the current design.  There probably should be some latching indication, perhaps in the TCB, that a signal interrupt has been received.

There is already a T CBTCB_FLAG_CANCEL_PENDING in the TCB that will tell us that the if the task has been canceled.  That flag is tested in the leave_cancellation_point() function so I don't think that there is any corresponding issue for thread cancellation.  We just need to make sure that all waits are aborted if ECANCELED is received and let the error indication ripple all they back to the leave_cancellation_point() function. Then the function will exit cleanly, safely, and quickly.

...