Killing threads (was Re: Cancel or timeout a long running regular expression)

[Antoon Pardon]

On Wed, Sep 21, 2011 at 07:41:50AM +0200, Martin v. Loewis wrote:
> > Is it just that nobody's implemented it, or is there a good reason for
> > avoiding offering this sort of thing?
> 
> I've been considering to implement killing threads several times for the
> last 15 years (I think about it once every year), and every time
> I give up because it's too complex and just not implementable.
> 
> To start with, a simple flag in the thread won't do any good.

I don't agree. Now if you had written that it wouldn't solve all
problem, I could understand that. But I have been in circumstances
where a simple flag in the thread implementation would have been
helpfull.

>                                                               It will
> not cancel blocking system calls, so people will complain that the
> threads they meant to cancel continue to run forever. Instead, you
> have to use some facility to interrupt blocking system calls. You
> then have to convince callers of those blocking system calls not to
> retry when they see that the first attempt to call it was interrupted.
> And so on.

But this is no longer an implementation problem but a use problem. If
someone gets an IOError for writing on a closed pipe and he cathes the
exception and retries the write in a loop, then this a problem of the
author of this loop, not of exceptions.

So if one thread throws an exception to an other thread for instance to
indicate a timeout for the latter and the latter catches that exception
and tries again what it was doing in a loop, that is entirely the
problem of the author of that loop and not of the abilty of one thread
throwing an exception in an other.

Unless of course there may be a lot of such problematic loops within
the internal python code.

-- 
Antoon Pardon