Interruptable sleep functions

[Next-Door-Tech]

The original versions of delayOld() and delayMicrosecondsOld() used nanosleep() not in a loop, meaning that if the process received a system interrupt signal sleep would halt and not resume, unless delayMicrosecondsHard() was used. Current implementations of delay() etc. do resume sleep if interrupted.

The new functions delayInterruptable(), delayMicrosecondsInterruptable(), and delayNanosecondsInterruptable() do not resume after a system interrupt is received, akin to the old non-hard delay functions.

The functions delay(), delayMicroseconds(), and delayNanoseconds() has been changed so that their calls to clock_nanosleep() are not inside a loop, mirroring the original behavior.

New non-interruptable functions delayNI(), delayMicrosecondsNI(), and delayNanosecondsNI() have been added alongside a new helper delayHelperNI() which are simply the loop-resuming versions of their counterparts before this change.

[Next-Door-Tech]

Up for discussion: should the behavior of the "default" versions of delay(), etc. be interruptable since this was the behavior of the original old versions (if not hard delaying), and the "uninterruptable" versions made into their own separately-named functions instead?

I'm thinking this may be the correct move since there may be some edge case where another project uses delay() to wait for an interrupt signal.

[mstroh76]

I think the new delay function should have the same behavior as the old one.
I will take a look at some WiringPi projects to see how the delay command is used there. Personally, I have never used long delays and have always handled signals myself.

[Next-Door-Tech]

I think the new delay function should have the same behavior as the old one.

Ok, in that case, I'll remove the loop around clock_nanosleep() from the "standard" versions of delay() etc. so that they behave exactly as the old versions did.

The non-interruptable behavior (loop included) is now in the non-interruptable functions delayNI() etc. These versions are simply copies of their counterparts before this change.

[Next-Door-Tech]

BTW, this should be the last major change to the delay() family. Ready for testing.