473,545 Members | 1,930 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Re: How to kill a thread?

John Dohn wrote:
Hi there,

How can I kill a threading.Threa d subclass from MainThread?

My threads are waiting for data in Queue.get() method:
class MyThread(thread ing.Thread):
def run(self):
while True:
data = queue.get() # <- here it waits most of the time
... process data

From the main thread I start several working threads:
thr = MyThread()
thr.start()
... feed the queue
and at the end for each thread I'd like to do something like thr.kill()
or thr.stop() or thr.destroy() or ... you got the point. I can't figure
out how.

Is there a way to do it?
When I do this, I put a special value in the queue (like None) and in
the worker thread, check for the special value and exit if found.

Threads can also be marked as "daemon threads" (see docs for
threading.Threa d objects). This will make the application terminate if
only "daemon threads" are left.

So best would probably be soemthing like

- call setDaemon() when creating worker threads
- ...
- send all worker/daemon threads None via queue
- wait some time, like time.sleep(1.0) , to let daemon exit themselves
- exit main application

-- Gerhard

Jun 27 '08 #1
20 5041
It's always been my understanding that you can't forcibly kill a thread
in Python (at least not in a portable way). The best you can do is
politely ask it to die, IIRC.

--
code.py: A blog about life, the universe, and Python

http://pythonista.wordpress.com
** Posted from http://www.teranews.com **
Jun 27 '08 #2
On Jun 6, 12:44 pm, The Pythonista <n...@this.time wrote:
It's always been my understanding that you can't forcibly kill a thread
in Python (at least not in a portable way). The best you can do is
politely ask it to die, IIRC.
Inherently, the best you can do in most languages is ask them politely
to die. Otherwise you'll leave locks and various other datastructures
in an inconvenient state, which is too complex to handle correctly.
The exception is certain functional languages, which aren't capable of
having threads and complex state in the same sense.

However, you could go quite far with a standardized mechanism of
politely asking threads to die. For instance, all blocking I/O
functions could be made to support it. This is how cancellation works
in python-safethread.
Jun 27 '08 #3
Would it be possible for a 3rd-party threading library to an
'interruptible' version of Queue?

The same methods as the normal Queue, but when you call a new .kill()
method on the queue, all the threads locking on the queue get a
"QueueKille d" exception thrown.

It might be as simple as a Queue wrapper where .kill() adds a speciall
Killed value to the queue, and the .get() wrapper throws a QueueKilled
exception (after re-putting Killed) when it reads Killed.

Locking for queues with a limited size is more complicated. Maybe
..kill() can also set an .killed attribute, and pop anything already in
the queue before putting Killed. Then when the put() wrapper unlocks,
it checks if .killed is set, and throws a QueueKilled exception.

One side-effect is that the queue becomes unusable (get & put now
immediately throw QueueKilled), unless you make a .unkill() method.

David
Jun 27 '08 #4
David <wi******@gmail .comwrote:
Would it be possible for a 3rd-party threading library to an
'interruptible' version of Queue?

The same methods as the normal Queue, but when you call a new .kill()
method on the queue, all the threads locking on the queue get a
"QueueKille d" exception thrown.

It might be as simple as a Queue wrapper where .kill() adds a speciall
Killed value to the queue, and the .get() wrapper throws a QueueKilled
exception (after re-putting Killed) when it reads Killed.
There seem to me to be 2 basic types of threads - I'll call them
client threads and server threads.

A client thread listens on a Queue for its instructions and replies
via a different Queue, or via Queues passed in in its instructions.
That kind of thread can easily have an instruction which means quit.
When it isn't processing instructions there is a nice clean moment for
it to quit. However if the processing takes a long time then there
will be a long wait for the thread to die. This is the scenario
described above.

The server type thread is processing all the time. Every now and
again it sends its results via a Queue. An example of this type of
thread might be one listening on a socket. This type of thread has no
nice moment to listen for instructions to quit as it might well be
blocked on something else (eg listening to a socket). To make this
type of thread kill nicely you have to go back to breaking up your
work into chunks (eg polling the socket asynchronously) and polling
the command queue to wait for your quit instruction which is wastefull
of CPU resources.

So it seems to me that there isn't a good solution to killing python
threads of either type, other than coding them carefully and checking
for quit instructions regularly.

You can kill them using the internal python API and ctypes, but you
run the risk of leaving things in an inconsistent state which is why
that API isn't exposed.

Here is an attempt at a killable thread

http://aspn.activestate.com/ASPN/Coo.../Recipe/496960

and

http://sebulba.wikispaces.com/recipe+thread2

Read the caveats!

--
Nick Craig-Wood <ni**@craig-wood.com-- http://www.craig-wood.com/nick
Jun 27 '08 #5
On 2008-06-07, Rhamphoryncus <rh****@gmail.c omwrote:
On Jun 6, 12:44 pm, The Pythonista <n...@this.time wrote:
>It's always been my understanding that you can't forcibly kill a thread
in Python (at least not in a portable way). The best you can do is
politely ask it to die, IIRC.

Inherently, the best you can do in most languages is ask them politely
to die. Otherwise you'll leave locks and various other datastructures
in an inconvenient state, which is too complex to handle correctly.
The exception is certain functional languages, which aren't capable of
having threads and complex state in the same sense.
Well it would of course depend on what is considered asking politely?

If one thread could cause an exception being thrown in an other thread,
would this be considered a polite way to ask? Would it be considered
an acceptable way?

--
Antoon Pardon
Jun 27 '08 #6
On 2008-06-07, David <wi******@gmail .comwrote:
Would it be possible for a 3rd-party threading library to an
'interruptible' version of Queue?

The same methods as the normal Queue, but when you call a new .kill()
method on the queue, all the threads locking on the queue get a
"QueueKille d" exception thrown.
I have done something similar. The idea was that threads had to open
a queue before they could access it. If the last thread who had the
queue open in write mode, closed the queue, a reader trying to get
an element from an empty queue would have an "EOInformat ion" exception
raised.

--
Antoon Pardon
Jun 27 '08 #7
On Jun 9, 5:33 am, Antoon Pardon <apar...@forel. vub.ac.bewrote:
On 2008-06-07, Rhamphoryncus <rha...@gmail.c omwrote:
On Jun 6, 12:44 pm, The Pythonista <n...@this.time wrote:
It's always been my understanding that you can't forcibly kill a thread
in Python (at least not in a portable way). The best you can do is
politely ask it to die, IIRC.
Inherently, the best you can do in most languages is ask them politely
to die. Otherwise you'll leave locks and various other datastructures
in an inconvenient state, which is too complex to handle correctly.
The exception is certain functional languages, which aren't capable of
having threads and complex state in the same sense.

Well it would of course depend on what is considered asking politely?

If one thread could cause an exception being thrown in an other thread,
would this be considered a polite way to ask? Would it be considered
an acceptable way?
The exception must not be raised until a point explicitly designed as
safe is hit. Otherwise, any function that manipulates data you'll
still use will potentially be buggered. Consider sys.stdout: codecs,
buffering, lots to go wrong.
Jun 27 '08 #8
On Jun 9, 9:20*pm, Rhamphoryncus <rha...@gmail.c omwrote:
On Jun 9, 5:33 am, Antoon Pardon <apar...@forel. vub.ac.bewrote:
On 2008-06-07, Rhamphoryncus <rha...@gmail.c omwrote:
On Jun 6, 12:44 pm, The Pythonista <n...@this.time wrote:
>It's always been my understanding that you can't forcibly kill a thread
>in Python (at least not in a portable way). *The best you can do is
>politely ask it to die, IIRC.
Inherently, the best you can do in most languages is ask them politely
to die. *Otherwise you'll leave locks and various other datastructures
in an inconvenient state, which is too complex to handle correctly.
The exception is certain functional languages, which aren't capable of
having threads and complex state in the same sense.
Well it would of course depend on what is considered asking politely?
If one thread could cause an exception being thrown in an other thread,
would this be considered a polite way to ask? Would it be considered
an acceptable way?

The exception must not be raised until a point explicitly designed as
safe is hit. *Otherwise, any function that manipulates data you'll
still use will potentially be buggered. *Consider sys.stdout: codecs,
buffering, lots to go wrong.

Java and .NET both have ways of killing threads. They both work by
raising a 'ThreadAbort' (or similar) exception in the target thread.
In early implementations they both suffered from a similar problem.
You could protect locks (etc) by having a finally block that would
release all resources as needed - but what happens if the thread abort
exception is raised *inside* the finally block?

Java responded by deprecating thread aborting. .NET responded by
ensuring that a thread abort exception would never be raised inside a
finally block - if that happened the exception would only be raised
once the code has left the finally block.

Aborting threads in .NET can be extremely useful. Politely asking a
thread to die is no good if the task the thread is executing is
extremely coarse grained - it may not be able to respond to the
request for some time. If your code is structured correctly
(performing a long running background calculation for example) then
you may *know* that you can kill it without problems, but Python has
no native API to do this.

Michael Foord
http://www.ironpythoninaction.com/
Jun 27 '08 #9
On Jun 9, 2:52 pm, Fuzzyman <fuzzy...@gmail .comwrote:
On Jun 9, 9:20 pm, Rhamphoryncus <rha...@gmail.c omwrote:
On Jun 9, 5:33 am, Antoon Pardon <apar...@forel. vub.ac.bewrote:
On 2008-06-07, Rhamphoryncus <rha...@gmail.c omwrote:
On Jun 6, 12:44 pm, The Pythonista <n...@this.time wrote:
It's always been my understanding that you can't forcibly kill a thread
in Python (at least not in a portable way). The best you can do is
politely ask it to die, IIRC.
Inherently, the best you can do in most languages is ask them politely
to die. Otherwise you'll leave locks and various other datastructures
in an inconvenient state, which is too complex to handle correctly.
The exception is certain functional languages, which aren't capable of
having threads and complex state in the same sense.
Well it would of course depend on what is considered asking politely?
If one thread could cause an exception being thrown in an other thread,
would this be considered a polite way to ask? Would it be considered
an acceptable way?
The exception must not be raised until a point explicitly designed as
safe is hit. Otherwise, any function that manipulates data you'll
still use will potentially be buggered. Consider sys.stdout: codecs,
buffering, lots to go wrong.

Java and .NET both have ways of killing threads. They both work by
raising a 'ThreadAbort' (or similar) exception in the target thread.
In early implementations they both suffered from a similar problem.
You could protect locks (etc) by having a finally block that would
release all resources as needed - but what happens if the thread abort
exception is raised *inside* the finally block?

Java responded by deprecating thread aborting. .NET responded by
ensuring that a thread abort exception would never be raised inside a
finally block - if that happened the exception would only be raised
once the code has left the finally block.

Aborting threads in .NET can be extremely useful. Politely asking a
thread to die is no good if the task the thread is executing is
extremely coarse grained - it may not be able to respond to the
request for some time. If your code is structured correctly
(performing a long running background calculation for example) then
you may *know* that you can kill it without problems, but Python has
no native API to do this.
So how does .NET deal with the sys.stdout corruption? Does it?

If you've carefully written your code to use only safe primitives and
local state (discarded if interrupted) then yes, it could be
interruptible. At this point you could specially mark that block of
code as safe, leaving the vast majority of other code unsafe by
default. Then again, since you're going to the trouble of carefully
designing and auditing your code you could just make it cancellable
like blocking I/O should be - just by polling a flag at key points
(and you're CPU-bound anyway, so it's not expensive.)

The only place I know of that you *need* arbitrary interruption is
hitting CTRL-C in the interactive interpreter. At this point it's a
debugging tool though, so the risk of weirdness is acceptable.
Jun 27 '08 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

12
18863
by: Jerry Sievers | last post by:
Greetings Pythonists; I have limited experience with threaded apps and plenty with old style forked heavyweight multi-processing apps. Using Python 2.3.3 on a Redhat 7.x machine. Wondering if there is a simple way from a main python program to kill a running thread? I see with the 'threading' module the way daemonic threads behave...
5
10916
by: Blatwurst | last post by:
I'm trying to implement a simple server in C#. I want to do the classic thing of spinning off a thread that just blocks in a Socket.Accept() call until a request comes in. At that point, the Accept() returns, the thread spins off another thread to handle the request, and then calls Accept() again. This all works fine except that I can find no...
6
42864
by: RickDee | last post by:
Understand that when I start a thread, a number will be generated and is able to get from GetHashCode method. But I would like to use this number when I want to kill certain thread, anybody know how ?? Thanks Regards
3
5830
by: Stewart | last post by:
Hey Group, Hoping someone can help me out. I have some code which starts up some asynchronous code using a delegate. The code is below. Basically my main code (not shown) calls ServerThreadStart.StartServer to start the server running asynchronously. This works fine. Shouldn't be any problems here. My question is how can I get my...
9
15267
by: Brett | last post by:
I'm trying to kill a thread spawned this way: Form1 spawns Class1 via Thread.start() Here's my code to kill the thread: If (t.ThreadState.ToString = "SuspendedRequested, WaitSleepJoin") Or (t.ThreadState.ToString = "Suspended") Or (t.ThreadState.ToString = "WaitSleepJoin, Suspended") Then Else t.Abort()
2
3490
by: Christopher Carnahan | last post by:
I need to figure out how to terminate a thread while it is blocked trying to create a COM object via interop. In a worker thread, I do something like this: Type t = null; Object activatedObject = null; Legacy.IScheduled comObject = null; t = Type.GetTypeFromProgID(ProgID);
5
10568
by: care02 | last post by:
Hi! I have the following problem: I have written a short Python server that creates an indefinite simulation thread that I want to kill when quitting (Ctrl-C) from Python. Googling around has not given me any hints on how to cleanly kill running threads before exiting. Any help is appreciated! Carl
18
10207
by: =?Utf-8?B?VGhlU2lsdmVySGFtbWVy?= | last post by:
Because C# has no native SSH class, I am using SharpSSH. Sometimes, for reasons I do not know, a Connect call will totally lock up the thread and never return. I am sure it has something to do with weirdness going on with the server I am talking to. Anyhow, this locked up state happens once in a while (maybe once per day) and I can't...
1
10363
by: =?Utf-8?B?QWxoYW1icmEgRWlkb3MgS2lxdWVuZXQ=?= | last post by:
Hi misters, Is it possible "kill" the thread of Backgroundworker ? In my Dowork event, I have NOT While for do e.Cancel = true, only have a call to external COM. If I want cancel, calling CancelAsync, not cancels the call to COM. How I can do it , please ? Any suggestions will be very appreciated.
0
7479
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main...
0
7411
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language...
1
7439
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
0
5987
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
1
5343
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes...
0
4962
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert...
0
3468
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in...
0
3450
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
1901
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.