469,949 Members | 2,546 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,949 developers. It's quick & easy.

Stopping a thread from another one

Hello Newsgroup!

In my Python script, I use the 'thread' module (not 'threading') and
'signal' simultaneously. All spawned threads execute
'pcapObject.loop(-1, callback)', which does not return.

The problem now is:
When the script catch a signal (let's say: SIGHUP), only the main thread
is affected. But I need also the subthreads to be ended, because the
script reopen()s files on SIGHUP and would also re-create the threads.

NOT a solution is:
The main thread sets a lock in the signal handler, the pcap-callback()
function examines this lock everytime it's called, and if set, exit()s
the thread. This is not very beautiful.
I would prefer, if I end the subthreads by the main thread.
Is there any chance?

Greetings,
fps
Jul 18 '05 #1
6 6812
Fabiano Sidler wrote:
Hello Newsgroup!

In my Python script, I use the 'thread' module (not 'threading') and
'signal' simultaneously. All spawned threads execute
'pcapObject.loop(-1, callback)', which does not return.

The problem now is:
When the script catch a signal (let's say: SIGHUP), only the main thread
is affected. But I need also the subthreads to be ended, because the
script reopen()s files on SIGHUP and would also re-create the threads.

NOT a solution is:
The main thread sets a lock in the signal handler, the pcap-callback()
function examines this lock everytime it's called, and if set, exit()s
the thread. This is not very beautiful.
I would prefer, if I end the subthreads by the main thread.
Is there any chance?

Greetings,
fps


Incorporating a flag into each thread, which is checked periodically by
the thread to decide whether or not it should end, is the safest way to
terminate threads. However, if you're looking for a preemptive method
that kills a thread unconditionally (whether the thread wants to die or
not) then search this group for 'Kthread', a module created by Connelly
Barnes, which implements a subclass of Thread incorporating this
feature. Note that killing threads preemptively is unsafe and should
only be done with care. This is why it's not part of Python's standard
threading library.
Jul 18 '05 #2
Fabiano Sidler wrote:
I would prefer, if I end the subthreads by the main thread.
Is there any chance?


The usual idiom is something like this:

class StoppableThread(threading.Thread):
def __init__(self):
threading.Thread.__init__(self)
self._running = False
def stop(self):
self._running = False
def run(self):
while self._running:
# do stuff here that loops periodically to allow
# the flag to be checked
Then from the main thread you can keep track of the child
threads and do xxx.stop() on each of them, then an optional
threading.Thread.join() call (check the docs for that).

This can be made more sophisticated as required.

-Peter
Jul 18 '05 #3
Op 2004-06-23, Chris S. schreef <ch*****@NOSPAMudel.edu>:
Fabiano Sidler wrote:
Hello Newsgroup!

In my Python script, I use the 'thread' module (not 'threading') and
'signal' simultaneously. All spawned threads execute
'pcapObject.loop(-1, callback)', which does not return.

The problem now is:
When the script catch a signal (let's say: SIGHUP), only the main thread
is affected. But I need also the subthreads to be ended, because the
script reopen()s files on SIGHUP and would also re-create the threads.

NOT a solution is:
The main thread sets a lock in the signal handler, the pcap-callback()
function examines this lock everytime it's called, and if set, exit()s
the thread. This is not very beautiful.
I would prefer, if I end the subthreads by the main thread.
Is there any chance?

Greetings,
fps


Incorporating a flag into each thread, which is checked periodically by
the thread to decide whether or not it should end, is the safest way to
terminate threads. However, if you're looking for a preemptive method
that kills a thread unconditionally (whether the thread wants to die or
not) then search this group for 'Kthread', a module created by Connelly
Barnes, which implements a subclass of Thread incorporating this
feature. Note that killing threads preemptively is unsafe and should
only be done with care. This is why it's not part of Python's standard
threading library.


I thought Python was a language for consenting adults.

--
Antoon Pardon
Jul 18 '05 #4
Antoon Pardon wrote:
Op 2004-06-23, Chris S. schreef <ch*****@NOSPAMudel.edu>:
Incorporating a flag into each thread, which is checked periodically by
the thread to decide whether or not it should end, is the safest way to
terminate threads. However, if you're looking for a preemptive method
that kills a thread unconditionally (whether the thread wants to die or
not) then search this group for 'Kthread', a module created by Connelly
Barnes, which implements a subclass of Thread incorporating this
feature. Note that killing threads preemptively is unsafe and should
only be done with care. This is why it's not part of Python's standard
threading library.


I thought Python was a language for consenting adults.


The "consulting adults" refrain comes from the idea that two people
should be allowed to engage in whatever behaviour they want,
together, if it's not harming anyone including themselves. It's
a social thing, you know, keep the government out of the bedroom.

Threads are too difficult, and multithreaded issues too little
understood by most people, to expect that people will not shoot
themselves in the foot with a thread.kill(). Newbies will see
that method and find all manner of creative ways to use it, none
of which will be either required or reliable.

Killing threads is an STD, and in this area Python makes you wear
a condom.

-Peter
Jul 18 '05 #5
Peter Hansen wrote:
Threads are too difficult, and multithreaded issues too little
understood by most people, to expect that people will not shoot
themselves in the foot with a thread.kill(). Newbies will see
that method and find all manner of creative ways to use it, none
of which will be either required or reliable.

Killing threads is an STD, and in this area Python makes you wear
a condom.


If I write the code for the threads then what exactly is the
problem?

As far as I can tell, implementing thread killing is something that
is difficult to implement in the interpretter, but rather than just
admit that, we get the "who will think of the newbies" cries instead.

Anybody can use os.remove. Do we prevent access to that? Heck,
I can subclass and not call parent constructors. Does Python
even bat an eyelid. I can open zillions of sockets and dump
spam down them. Not a peep from Python.

I can make multiple threads of execution and put in all
sorts of deadlocks. I can even write infinite loops trivially.
No sound from Python.

We already have signals and keyboardinterrupt in the main
thread and the world hasn't collapsed. I don't exactly see
how it will suddenly collapse if the same can be done to
other threads.

Roger
Jul 18 '05 #6
Op 2004-06-23, Peter Hansen schreef <pe***@engcorp.com>:
Antoon Pardon wrote:
Op 2004-06-23, Chris S. schreef <ch*****@NOSPAMudel.edu>:
Incorporating a flag into each thread, which is checked periodically by
the thread to decide whether or not it should end, is the safest way to
terminate threads. However, if you're looking for a preemptive method
that kills a thread unconditionally (whether the thread wants to die or
not) then search this group for 'Kthread', a module created by Connelly
Barnes, which implements a subclass of Thread incorporating this
feature. Note that killing threads preemptively is unsafe and should
only be done with care. This is why it's not part of Python's standard
threading library.


I thought Python was a language for consenting adults.


The "consulting adults" refrain comes from the idea that two people
should be allowed to engage in whatever behaviour they want,
together, if it's not harming anyone including themselves. It's
a social thing, you know, keep the government out of the bedroom.

Threads are too difficult, and multithreaded issues too little
understood by most people, to expect that people will not shoot
themselves in the foot with a thread.kill(). Newbies will see
that method and find all manner of creative ways to use it, none
of which will be either required or reliable.

Killing threads is an STD, and in this area Python makes you wear
a condom.


And who decides that?

Whenever someone comes up with an idea that will help prevent
people from shooting themselves in the foot, I hear the:
"Python is for consenting adults" mantra, don't take away
the flexibility of the language. Now suddenly the situation
is reversed and people ask for more flexibility and suddenly
the extra flexibility is like as STD and the consenting
adults idea not so strong as originally presented.

My impression with all that Python Zen is that people
just use it to resist change. Explicit is better than
implicit except where python currently already does things
implicitly. Python is for consenting adults except
where python has already limitations because those
limitations are for preventing STD.

--
Antoon Pardon
Jul 18 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by traviscook88 | last post: by
2 posts views Thread by matteo | last post: by
11 posts views Thread by Steve | last post: by
4 posts views Thread by bjm | last post: by
10 posts views Thread by archana | last post: by
4 posts views Thread by =?iso-8859-1?B?S2VyZW0gR/xtcvxrY/w=?= | last post: by
2 posts views Thread by Steve | last post: by
1 post views Thread by raghudr | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.