Stopping a thread from another one

[Fabiano Sidler]

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

 

[Chris S.]

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.

 

[Peter Hansen]

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

 

[Antoon Pardon]

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.

 

[Peter Hansen]

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

 

[Roger Binns]

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

 

[Antoon Pardon]

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.