nuttx-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <>
Subject [GitHub] [incubator-nuttx] patacongo commented on issue #619: Uninterruptible semaphore waits breaks cancellation.
Date Tue, 07 Apr 2020 17:47:27 GMT
patacongo commented on issue #619: Uninterruptible semaphore waits breaks cancellation.
   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:

With regards,
Apache Git Services

View raw message