I certainly did not mean “signal” in a purely binary way.   Nor, so specific.   Rather, a better word might simply be, “inform” or “notify.”

The thread, presumably, is doing something; it is working on some particular request or unit of work, presumably in teamwork with some other thread(s).   So, if this thread has timed-out, in the grand scheme of things it probably needs to inform someone (maybe not the parent) about something related to that unit-of-work’s new status.   It is just a worker bee, not the workflow manager.

“Putting a bomb in your own backpack” is the best way of handling timeouts vs. having some executioner-process out there with a loaded gun, and as far as I know that’s how every workflow management package does it.   The worker sets the timer, does the work, and, 99.9% of the time, clears the timer, sends a success-notification to whomever needs to receive it, and all is well.   Maybe it terminates, or maybe it simply starts afresh on a new unit of work.   Timeout throws it into an exception-handler ... the thread is still alive but now it’s in that handler ... and it sends a failure message to the appropriate parties before (perhaps...) cordially terminating itself.   Whether it succeeds or it fails, with one unit of work or with many, it always exits the stage graciously, never having been murdered by anyone.