sleep should be a thread cancellation point

[Alexandre Oliva]

GCC has worked around, in the libstdc++ testsuite, the fact that nanosleep (as well as sleep and clock_nanosleep) should be thread cancellation points, per POSIX, but RTEMS may want to make them so.
​https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597003.html

(I haven't checked that other functions that should be thread cancellation points are, I only noticed that this one wasn't, and decided to file this ticket because for other issues in which I explicitly identified RTEMS I got a request to do so)

[Sebastian Huber]

Thanks for reporting the issue. I think we have currently no cancellation points in RTEMS at all. I think this is intentional, so I would mark this bug as WONTFIX.

[Joel Sherrill]

Do you have a test to show something isn't right? sleep() and nanonsleep() ultimately call clock_nanosleep() and the requested blocking state is "STATES_WAITING_FOR_TIME | STATES_INTERRUPTIBLE_BY_SIGNAL"

​https://git.rtems.org/rtems/tree/cpukit/posix/src/clocknanosleep.c#n77

RTEMS state bits consist of the type of object is being blocked on and attributes such as interruptible. It has been this way for a LONG time.

As a random thought, if you don't build RTEMS with POSIX enabled, then POSIX signals are disabled and then this likely wouldn't work.

[Alexandre Oliva]

The unpatched libstdc++ testcase is a test that shows the problem.
An explicit pthread_testcancel shouldn't be needed.
Functions that are cancellation points should (as-if) call it implicitly.