Re: Threads Timeout

The basic idea here is definitely the right approach: let the thread set a timeout upon itself, so that when 31 seconds arrive ... the thread does not keep going, wasting CPU time to produce a result that will never be interesting. Instead, it dies. This is much more reliable in-practice than having a separate process out there with a stopwatch in its hands, which is quite vulnerable to edge-case race conditions. Let each thread be fully responsible for its own outcome, whatever that may be, and for dealing with it and for reporting it.

The only thing that I do not see here (having only glanced at the responses most casually and briefly, is that usually the thread, before dying, needs to in some way signal a waiting parent that it has failed. Perhaps the final-status of the thread is enough to do that, or you might need to add code to send some kind of a message to someone (perhaps, to a process that isn’t the parent) to the effect that such-and-such a unit of work could not be completed timely. Several ways to tackle that, of course ... maybe the parent does it, and maybe not ... and mind you, I’m not suggesting that the solutions offered here so-far do not work because they most clearly do.

Replies are listed 'Best First'.
Re^2: Threads Timeout by BrowserUk (Patriarch) on Jan 23, 2012 at 19:44 UTC
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?	[reply]
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]