Re^2: Threads Timeout

The only thing that I do not see here ... is that usually the thread, before dying, needs to in some way signal a waiting parent that it has failed.

You are suggesting that the children signal their parent. Inter-thread communication with a bandwidth of a whole 1-bit.

What would the parent do with the knowledge that 'one of its kids has died'? With that 1 bit bandwidth you cannot even communicate which child has died.

A bit like a station announcer telling you: "a train arrived or departed".

And that is ignoring the fact that inter-thread signalling doesn't work as there is no way to distinguish the source of the signal -- inter-thread or inter-process -- never mind which thread. In addition, every thread within the process that has a signal handler defined, will receive every signal regardless of where it originated from.

All a little pointless when you have the unlimited bandwidth of the return from the join.

I just wonder why you felt the need to suggest this when you've obviously not even attempted to think through the implications, much less actually tried it.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Comment on Re^2: Threads Timeout

Replies are listed 'Best First'.
Re^3: Threads Timeout by locked_user sundialsvc4 (Abbot) on Jan 24, 2012 at 14:55 UTC
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.
Re^4: Threads Timeout by BrowserUk (Patriarch) on Jan 24, 2012 at 15:30 UTC
I certainly did not mean “signal” in a purely binary way. Hm. For a man apparently with so much experience, you might be more careful about overloading industry standard terms. in the grand scheme of things it probably needs to inform someone The OP clearly stated: "I would like to kill that thread, disregard result ...". (My emphasis!) With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. The start of some sanity?	[reply]