[GitHub] [incubator-nuttx] patacongo commented on issue #619: Uninterruptible semaphore waits breaks cancellation.

[GitBox <gi...@apache.org>]

patacongo commented on issue #619: Uninterruptible semaphore waits breaks cancellation.
URL: https://github.com/apache/incubator-nuttx/issues/619#issuecomment-610529195
 
 
   I refer to those use cases as mutual exclusion sempahores, and signaling semaphores.  I think both should work the same:  For both the semaphore wait should be terminated and correct error should be returned.
   
   If the API requires returning EINTR if a signal is received, we should return the error.  This is required in most POSIX interfaces and don't see how you could avoid that.  However, the mutual exclusion semaphores are the just there for the correctness in the design.  There is seldom any real competitor for the exclusion semaphore and, in general, they never block and, hence, would never generate the error.
   
   And even if taking the mutual exclusion semaphore does cause the thread to block, it should block form only a very brief moment of time and the likelihood of a signal received or of the task being canceled is very small.
   
   But if there is even a small possibility of that event happening, it WILL happen in an embedded system.
   
   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.
   
   But 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 different story.  The 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.  But we have no difference of opinion on that.
   
   There is really no difference in the actions that must be taken if a signal is received of if the task is canceled.  Both mutual exclusion semaphores and signaling semaphores should wake up and return the error condition.  The only real differences is that mutual exclusion semaphores either do not block or, if they do, the do not block as long.
   
   
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services