It is just like: worker is waiting for his next command on production line, but he should go outside immediately once fire alarm happened.
Not a clean, recommended way, no.
There are good alternatives though. For example, you can insert the fire alarm into the queue of commands. Or you can use task notifications as a lightweight event group, which allows you to wait for any of several events at once.
I think that xTaskAbortDelay will give the task an immediate timeout return.
But only if the task was blocked when
xTaskAbortDelay is called. This might cause race conditions…
Perhaps with an additional, atomic/volatile alert flag this could work reliably.
The fire alarm could be inserted to the front of the queue that the message pump task waits on, so that alarm gets first priority over other events (this supplements Jeff’s suggestion).
Thanks Jeff and RAc, that will be good work aground solution. Also thanks for Richard and hs2.