Page History

...

But if during the that brief moment while the thread is blocked, a signal is received, I think that it is correct to return -EINTR. This is not so critical only because such an event it is rare.  But the specification requires it so we should do it.

And there are situations were the task may block for a very long time, even indefinitely, on a mutual exclusion semahore.  Consider the following scenario:  A driver that reads data could have a sequence like this:

1. Get exclusive access to the driver by taking a semaphore
2. Wait on a semaphore for data (might be a long time)
3. Release the mutual exclusion semaphore.

Now suppose there are two applications, Task A and Task B, that open the driver and try to read from it. The first, Task A, will get the mutual exclusion semaphore at (1) and then will hang waiting for data at (2).  It may have to wait for a very long time to receive data.  When re-entered by the second, Task B, will hang at (1) also for very long time.  Task B is effectively queued and cannot event begin its wait on the signaling semphore until Task B receives its data and releases the mutual exclusion semaphore. This is normal behavior and exactly, how this kind of driver is supposed to work.

But now suppose that Task B receives a signal interrupt or a cancellation event while waiting on the mutual exclusion semaphore. It MUST terminate the wait and return -EINTR or -ECANCEL immediately. Task A may never receive data and if that action is not taken, the signal interrup or cancellation event is lost and the functionality has failed.

The 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.

...