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

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

patacongo edited a comment on issue #619: Uninterruptible semaphore waits breaks cancellation.
URL: https://github.com/apache/incubator-nuttx/issues/619#issuecomment-610536661
 
 
   Currently, the only way for an OS interface function to know if a signal was received is to be awakened with an EINTR error.  That is why is is critical to always return the EINTR error and conform with the POSIX requirements.
   
   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 global indication, perhaps in the TCB, that a signal has been received.
   
   There is already a TCB_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.
   
   Interestingly, the ECANCELED error will never be seen by the application.  It just triggers the return uwind sequence where all resources are recovered and finally until leave_cancellation_point is called -- then the thread will exit before it returns to applicaton.
   
   You can see all of this working in the board/sim/sim/sim/configs/ostest configuration if you also enable:
   
       CONFIG_CANCELLATION_POINTS=y
       CONFIG_PTHREAD_CLEANUP=y
   
   There is a cancel.c test, but the more intesting is the pthread_cleanup.c test.  You can see how all this works when the code unwinds with the ECANCELED error and calls leave_cancellation_point.
   
   We probably should add those settingst to that otest defconfig
   
   

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