Re: Interrput a thread
On Jan 4, 10:53 pm, John Nagle na...@animats.com wrote: There are systems where there's support designed in for thread abort. LISP/Scheme systems tend to support it. QNX, the real-time OS, has well worked out thread-abort semantics at the C level. (QNX has really good features for not getting stuck, like the ability to put a time limit on any system call.) Yes, but not getting stuck and ending the thread execution is only one small part of the problem (and arguably the least significant). What we really want is a way to abort without harming other threads of execution, which is the hard part. QNX doesn't ipso facto make that easier. Functionality like time limits on system calls is more about latency guarantees and priority than getting stuck in a deadlock sense. What you'd really like in Python is the ability for one thread to be able to force an exception in another thread, plus a mechanism for locking out such exceptions for critical sections. It's not worth having, though, in a system where you can really only run one thread at a time. Exceptions and critical sections are rather fundamentally incompatible, hence the absurd amount of gymnastics .NET goes through to attempt to make ThreadAbortException functional (and still fails rather miserably). If you had STM or 'antitry' blocks, then exceptions might be a semi-saneish way to abort a thread. Without either, I'm not entirely convinced of the utility. Only allowing the exception to be thrown from defined cancellation points is much better (ala POSIX threads), but diminishes the utility for things that are mostly grinding away in userspace. Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: Interrput a thread
On 4 Gen, 07:13, Jean-Paul Calderone calderone.jeanp...@gmail.com wrote: On Jan 3, 6:17 pm, Adam Skutt ask...@gmail.com wrote: On Jan 3, 5:24 pm, Jean-Paul Calderone calderone.jeanp...@gmail.com wrote: Of course. The whole point here is not about threads vs processes. It's about shared memory concurrency vs non-shared memory concurrency. You can implement both with threads and both with processes, but threads are geared towards shared memory and processes are geared towards non-shared memory. So what most people mean by use processes is don't use shared memory. This is entirely my presumption, but I think if the OP were keenly aware of the differences between thread and processes, it's pretty likely he wouldn't have asked his question in the first place. Fair enough. :) Also, I've written lots and lots of use processes code on multiple platforms, and much of it has used some sort of shared memory construct. It's actually pretty common, especially in code bases with a lot of history. Not all the world is Apache. Hee hee, Apache. :) Adam- Nascondi testo citato - Mostra testo citato - BTW thanks for the suggestions. As in my original code snippet, the shared object that the threads are using is the Queue, that itself implement locking mechanism so I don't have to worry about concurrent access. Regarding my question, it was just to have a hint on how a thread termination can be handled as, per example, you have the consumer-producer pattern. Mattia -- http://mail.python.org/mailman/listinfo/python-list
Re: Interrput a thread
On Dec 29 2010, 11:31 pm, gervaz ger...@gmail.com wrote:
Hi all, I need to stop a threaded (using CTR+C or kill) application if
it runs too much or if I decide to resume the work later.
I come up with the following test implementation but I wanted some
suggestion from you on how I can implement what I need in a better or
more pythonic way. Here the code:
This is a case that .NET (C#) handles better than Python or Java.
It is unsafe to terminate an os level thread at an arbitrary point
because it may be executing code in a critical section. Both Java
and .NET used to provide ways to terminate threads safely by raising
an asynchronous exception in the thread. Releasing locks (etc) that
the thread holds could then be done in a finally section protecting
the code. Python doesn't allow you to abort threads.
Unfortunately the thread abort exception could also be raised in the
finally section - prematurely aborting the lock / resource cleanup.
Java handled this by deprecating thread aborting. (Python has never
had it I believe.)
.NET handled it by changing the semantics of thread aborting - the
thread abort exception will never be raised in a finally block. This
makes thread aborting safe, although technically you can subvert it by
putting all your code in a finally block (you can also catch and
cancel the thread abort exception).
The standard advice is to use a flag and do manual checking to abort
threads. This only works for fine grained operations and *doesn't*
work for very coarse grained operations or where there aren't
convenient places to check the flag. It's another place where people
sometimes have a genuine need/use case yet people will insist on
telling them they don't *really* want it...
Anyway, although there are ways based on ctypes to abort Python
threads it's not really safe. If you google you should find them,
hopefully with intelligible caveat emptor warnings...
All the best,
Michael Foord
import os
import signal
import time
from threading import Thread, current_thread
from queue import LifoQueue, Empty
COMMAND = {STOP: 0, NORMAL: 1}
THREAD_NUM = 5
lq = LifoQueue()
print({0}\n.format(os.getpid()))
class InterceptInterrupt(Exception):
pass
class Handler:
def __init__(self, queue):
self._queue = queue
def __del__(self):
print(Bye bye!)
def getHandler(self, signum, frame):
print(Interrupt raised!)
for _ in range(THREAD_NUM):
self._queue.put((COMMAND[STOP], None))
raise InterceptInterrupt
h = Handler(lq)
signal.signal(signal.SIGINT, h.getHandler)
for i in range(25):
lq.put((COMMAND[NORMAL], i))
def do_work(queue):
while True:
time.sleep(5)
try:
cmd, value = queue.get(block=False)
if cmd == COMMAND[STOP]:
print({0}: STOP command
received!.format(current_thread().name))
break
elif cmd == COMMAND[NORMAL]:
print(value)
except Empty:
break
threads = [Thread(target=do_work, args=(lq,)) for _ in
range(THREAD_NUM)]
for t in threads:
t.start()
while not lq.empty():
try:
time.sleep(1)
except (IOError, InterceptInterrupt):
break
for t in threads:
t.join()
if lq.empty():
print(The queue is empty.)
else:
print(The queue is NOT empty. Some additional work has to be
done.)
Thank you,
Mattia
--
http://mail.python.org/mailman/listinfo/python-list
Re: Interrput a thread
On Jan 4, 3:12 pm, Fuzzyman fuzzy...@gmail.com wrote:
On Dec 29 2010, 11:31 pm, gervaz ger...@gmail.com wrote:
Hi all, I need to stop a threaded (using CTR+C or kill) application if
it runs too much or if I decide to resume the work later.
I come up with the following test implementation but I wanted some
suggestion from you on how I can implement what I need in a better or
more pythonic way. Here the code:
This is a case that .NET (C#) handles better than Python or Java.
Heh, so one possible option is to use IronPython :-)
Michael Foord
It is unsafe to terminate an os level thread at an arbitrary point
because it may be executing code in a critical section. Both Java
and .NET used to provide ways to terminate threads safely by raising
an asynchronous exception in the thread. Releasing locks (etc) that
the thread holds could then be done in a finally section protecting
the code. Python doesn't allow you to abort threads.
Unfortunately the thread abort exception could also be raised in the
finally section - prematurely aborting the lock / resource cleanup.
Java handled this by deprecating thread aborting. (Python has never
had it I believe.)
.NET handled it by changing the semantics of thread aborting - the
thread abort exception will never be raised in a finally block. This
makes thread aborting safe, although technically you can subvert it by
putting all your code in a finally block (you can also catch and
cancel the thread abort exception).
The standard advice is to use a flag and do manual checking to abort
threads. This only works for fine grained operations and *doesn't*
work for very coarse grained operations or where there aren't
convenient places to check the flag. It's another place where people
sometimes have a genuine need/use case yet people will insist on
telling them they don't *really* want it...
Anyway, although there are ways based on ctypes to abort Python
threads it's not really safe. If you google you should find them,
hopefully with intelligible caveat emptor warnings...
All the best,
Michael Foord
import os
import signal
import time
from threading import Thread, current_thread
from queue import LifoQueue, Empty
COMMAND = {STOP: 0, NORMAL: 1}
THREAD_NUM = 5
lq = LifoQueue()
print({0}\n.format(os.getpid()))
class InterceptInterrupt(Exception):
pass
class Handler:
def __init__(self, queue):
self._queue = queue
def __del__(self):
print(Bye bye!)
def getHandler(self, signum, frame):
print(Interrupt raised!)
for _ in range(THREAD_NUM):
self._queue.put((COMMAND[STOP], None))
raise InterceptInterrupt
h = Handler(lq)
signal.signal(signal.SIGINT, h.getHandler)
for i in range(25):
lq.put((COMMAND[NORMAL], i))
def do_work(queue):
while True:
time.sleep(5)
try:
cmd, value = queue.get(block=False)
if cmd == COMMAND[STOP]:
print({0}: STOP command
received!.format(current_thread().name))
break
elif cmd == COMMAND[NORMAL]:
print(value)
except Empty:
break
threads = [Thread(target=do_work, args=(lq,)) for _ in
range(THREAD_NUM)]
for t in threads:
t.start()
while not lq.empty():
try:
time.sleep(1)
except (IOError, InterceptInterrupt):
break
for t in threads:
t.join()
if lq.empty():
print(The queue is empty.)
else:
print(The queue is NOT empty. Some additional work has to be
done.)
Thank you,
Mattia
--
http://mail.python.org/mailman/listinfo/python-list
Re: Interrput a thread
In article 2ebc11a5-1b45-4faa-97b9-c84f0db01...@k22g2000yqh.googlegroups.com, Fuzzyman fuzzy...@gmail.com wrote: It is unsafe to terminate an os level thread at an arbitrary point because it may be executing code in a critical section. [...] The standard advice is to use a flag and do manual checking to abort threads. This only works for fine grained operations and *doesn't* work for very coarse grained operations or where there aren't convenient places to check the flag. Another possibility is to not use threads! If you 1) Need asynchronous operation 2) Need iterruptability 3) Can't poll for an please stop signal You should look at running your thread as a separate process, which you can send a kill signal to when you want it to go away. You can then communicate with it via pipes, sockets, shared memory segments, whatever. Threads are a wonderful invention, but they are not a panacea for all possible parallelism tasks. Sometimes they're just the wrong tool. -- http://mail.python.org/mailman/listinfo/python-list
Re: Interrput a thread
On Jan 4, 3:31 pm, Roy Smith r...@panix.com wrote: In article 2ebc11a5-1b45-4faa-97b9-c84f0db01...@k22g2000yqh.googlegroups.com, Fuzzyman fuzzy...@gmail.com wrote: It is unsafe to terminate an os level thread at an arbitrary point because it may be executing code in a critical section. [...] The standard advice is to use a flag and do manual checking to abort threads. This only works for fine grained operations and *doesn't* work for very coarse grained operations or where there aren't convenient places to check the flag. Another possibility is to not use threads! If you 1) Need asynchronous operation 2) Need iterruptability 3) Can't poll for an please stop signal You should look at running your thread as a separate process, which you can send a kill signal to when you want it to go away. You can then communicate with it via pipes, sockets, shared memory segments, whatever. Threads are a wonderful invention, but they are not a panacea for all possible parallelism tasks. Sometimes they're just the wrong tool. However some tasks / algorithms are done much better with threads than processes. Asynchronous operations are good for IO bound concurrency but not for CPU bound concurrency. Michael Foord -- http://www.voidspace.org.uk/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Interrput a thread
On Jan 4, 12:31 pm, Fuzzyman fuzzy...@gmail.com wrote: On Jan 4, 3:31 pm, Roy Smith r...@panix.com wrote: In article 2ebc11a5-1b45-4faa-97b9-c84f0db01...@k22g2000yqh.googlegroups.com, Fuzzyman fuzzy...@gmail.com wrote: It is unsafe to terminate an os level thread at an arbitrary point because it may be executing code in a critical section. [...] The standard advice is to use a flag and do manual checking to abort threads. This only works for fine grained operations and *doesn't* work for very coarse grained operations or where there aren't convenient places to check the flag. Another possibility is to not use threads! If you 1) Need asynchronous operation 2) Need iterruptability 3) Can't poll for an please stop signal You should look at running your thread as a separate process, which you can send a kill signal to when you want it to go away. You can then communicate with it via pipes, sockets, shared memory segments, whatever. Threads are a wonderful invention, but they are not a panacea for all possible parallelism tasks. Sometimes they're just the wrong tool. However some tasks / algorithms are done much better with threads than processes. Asynchronous operations are good for IO bound concurrency but not for CPU bound concurrency. Asynchronous and threads aren't mutually exclusive. An asynchronous multithreading or multiprocessing library is perfectly well suited for CPU bound concurrency. Michael Foord --http://www.voidspace.org.uk/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Interrput a thread
On Jan 4, 10:12 am, Fuzzyman fuzzy...@gmail.com wrote: This is a case that .NET (C#) handles better than Python or Java. Nope, read the documentation for Thread.Abort() carefully. Thread.Abort() can cause termination inside a static constructor, which is very bad. You sure your application can cope with that? Mine can't. Thread.Abort() is only safe for self-abortion, app domain termination and a few other very narrow and obscure scenarios. It is not a safe way to end arbitrary threads doing arbitrary processing. It's another place where people sometimes have a genuine need/use case yet people will insist on telling them they don't *really* want it... Because there's no safe way to do it. It's fundamentally a racy operation, with the typical horrible consequences when you lose. Removing the race requires support from the application, i.e., you have to write the code yourself. Frequently, it's simply not possible to remove the race. Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: Interrput a thread
On 1/4/2011 6:11 PM, Adam Skutt wrote: On Jan 4, 10:12 am, Fuzzymanfuzzy...@gmail.com wrote: This is a case that .NET (C#) handles better than Python or Java. Nope, read the documentation for Thread.Abort() carefully. Thread.Abort() can cause termination inside a static constructor, which is very bad. You sure your application can cope with that? Mine can't. Thread.Abort() is only safe for self-abortion, app domain termination and a few other very narrow and obscure scenarios. It is not a safe way to end arbitrary threads doing arbitrary processing. It's another place where people sometimes have a genuine need/use case yet people will insist on telling them they don't *really* want it... Because there's no safe way to do it. It's fundamentally a racy operation, with the typical horrible consequences when you lose. Removing the race requires support from the application, i.e., you have to write the code yourself. Frequently, it's simply not possible to remove the race. There are systems where there's support designed in for thread abort. LISP/Scheme systems tend to support it. QNX, the real-time OS, has well worked out thread-abort semantics at the C level. (QNX has really good features for not getting stuck, like the ability to put a time limit on any system call.) But Python doesn't support things like that. What you'd really like in Python is the ability for one thread to be able to force an exception in another thread, plus a mechanism for locking out such exceptions for critical sections. It's not worth having, though, in a system where you can really only run one thread at a time. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Interrput a thread
gervaz ger...@gmail.com writes: On 31 Dic 2010, 23:25, Alice Bevan–McGregor al...@gothcandy.com wrote: On 2010-12-31 10:28:26 -0800, John Nagle said: Even worse, sending control-C to a multi-thread program is unreliable in CPython. See http://blip.tv/file/2232410; for why. It's painful. AFIK, that has been resolved in Python 3.2 with the introduction of an intelligent thread scheduler as part of the GIL release/acquire process. - Alice. Ok, but then suppose I have multiple long running threads that I want to delete/suspend because they are tooking too much time, which solution do you propose? If possible, use multiple processes instead. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Interrput a thread
On 3 Gen, 17:47, de...@web.de (Diez B. Roggisch) wrote: gervaz ger...@gmail.com writes: On 31 Dic 2010, 23:25, Alice Bevan–McGregor al...@gothcandy.com wrote: On 2010-12-31 10:28:26 -0800, John Nagle said: Even worse, sending control-C to a multi-thread program is unreliable in CPython. See http://blip.tv/file/2232410; for why. It's painful. AFIK, that has been resolved in Python 3.2 with the introduction of an intelligent thread scheduler as part of the GIL release/acquire process. - Alice. Ok, but then suppose I have multiple long running threads that I want to delete/suspend because they are tooking too much time, which solution do you propose? If possible, use multiple processes instead. Diez- Nascondi testo citato - Mostra testo citato - Multiple processes, ok, but then regarding processes' interruption there will be the same problems pointed out by using threads? Mattia -- http://mail.python.org/mailman/listinfo/python-list
Re: Interrput a thread
On Jan 3, 3:22 pm, gervaz ger...@gmail.com wrote: On 3 Gen, 17:47, de...@web.de (Diez B. Roggisch) wrote: gervaz ger...@gmail.com writes: On 31 Dic 2010, 23:25, Alice Bevan–McGregor al...@gothcandy.com wrote: On 2010-12-31 10:28:26 -0800, John Nagle said: Even worse, sending control-C to a multi-thread program is unreliable in CPython. See http://blip.tv/file/2232410; for why. It's painful. AFIK, that has been resolved in Python 3.2 with the introduction of an intelligent thread scheduler as part of the GIL release/acquire process. - Alice. Ok, but then suppose I have multiple long running threads that I want to delete/suspend because they are tooking too much time, which solution do you propose? If possible, use multiple processes instead. Diez- Nascondi testo citato - Mostra testo citato - Multiple processes, ok, but then regarding processes' interruption there will be the same problems pointed out by using threads? No. Processes can be terminated easily on all major platforms. See `os.kill`. Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Interrput a thread
On Jan 3, 4:06 pm, Jean-Paul Calderone calderone.jeanp...@gmail.com wrote: Multiple processes, ok, but then regarding processes' interruption there will be the same problems pointed out by using threads? No. Processes can be terminated easily on all major platforms. See `os.kill`. Yes, but that's not the whole story, now is it? It's certainly much more reliable and easier to kill a process. It's not any easier to do it and retain defined behavior, depending on exactly what you're doing. For example, if you kill it while it's in the middle of updating shared memory, you can potentially incur undefined behavior on the part of any process that can also access shared memory. In short, taking a program that uses threads and shared state and simply replacing the threads with processes will likely not gain you a thing. It entirely depends on what those threads are doing and how they do it. Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: Interrput a thread
On 3 Gen, 22:17, Adam Skutt ask...@gmail.com wrote: On Jan 3, 4:06 pm, Jean-Paul Calderone calderone.jeanp...@gmail.com wrote: Multiple processes, ok, but then regarding processes' interruption there will be the same problems pointed out by using threads? No. Processes can be terminated easily on all major platforms. See `os.kill`. Yes, but that's not the whole story, now is it? It's certainly much more reliable and easier to kill a process. It's not any easier to do it and retain defined behavior, depending on exactly what you're doing. For example, if you kill it while it's in the middle of updating shared memory, you can potentially incur undefined behavior on the part of any process that can also access shared memory. In short, taking a program that uses threads and shared state and simply replacing the threads with processes will likely not gain you a thing. It entirely depends on what those threads are doing and how they do it. Adam As per the py3.1 documentation, os.kill is only available in the Unix os. Regarding the case pointed out by Adam I think the best way to deal with it is to create a critical section so that the shared memory will be updated in an atomic fashion. Btw it would be useful to take a look at some actual code/documentation in order to understand how others dealt with the problem... Ciao, Mattia -- http://mail.python.org/mailman/listinfo/python-list
Re: Interrput a thread
On Jan 3, 4:17 pm, Adam Skutt ask...@gmail.com wrote: On Jan 3, 4:06 pm, Jean-Paul Calderone calderone.jeanp...@gmail.com wrote: Multiple processes, ok, but then regarding processes' interruption there will be the same problems pointed out by using threads? No. Processes can be terminated easily on all major platforms. See `os.kill`. Yes, but that's not the whole story, now is it? It's certainly much more reliable and easier to kill a process. It's not any easier to do it and retain defined behavior, depending on exactly what you're doing. For example, if you kill it while it's in the middle of updating shared memory, you can potentially incur undefined behavior on the part of any process that can also access shared memory. Then don't use shared memory. In short, taking a program that uses threads and shared state and simply replacing the threads with processes will likely not gain you a thing. It entirely depends on what those threads are doing and how they do it. Of course. The whole point here is not about threads vs processes. It's about shared memory concurrency vs non-shared memory concurrency. You can implement both with threads and both with processes, but threads are geared towards shared memory and processes are geared towards non-shared memory. So what most people mean by use processes is don't use shared memory. Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Interrput a thread
gervaz ger...@gmail.com writes: On 3 Gen, 22:17, Adam Skutt ask...@gmail.com wrote: On Jan 3, 4:06 pm, Jean-Paul Calderone calderone.jeanp...@gmail.com wrote: Multiple processes, ok, but then regarding processes' interruption there will be the same problems pointed out by using threads? No. Processes can be terminated easily on all major platforms. See `os.kill`. Yes, but that's not the whole story, now is it? It's certainly much more reliable and easier to kill a process. It's not any easier to do it and retain defined behavior, depending on exactly what you're doing. For example, if you kill it while it's in the middle of updating shared memory, you can potentially incur undefined behavior on the part of any process that can also access shared memory. In short, taking a program that uses threads and shared state and simply replacing the threads with processes will likely not gain you a thing. It entirely depends on what those threads are doing and how they do it. Adam As per the py3.1 documentation, os.kill is only available in the Unix os. Regarding the case pointed out by Adam I think the best way to deal with it is to create a critical section so that the shared memory will be updated in an atomic fashion. Btw it would be useful to take a look at some actual code/documentation in order to understand how others dealt with the problem... There is the multiprocessing module. It's a good start, and works cross-platform. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Interrput a thread
On Jan 3, 5:05 pm, gervaz ger...@gmail.com wrote: Regarding the case pointed out by Adam I think the best way to deal with it is to create a critical section so that the shared memory will be updated in an atomic fashion. Ok, so if the OS kills the process between taking the lock and releasing it, what are you going to do? Handled naively, you can end up in a deadlock situation[1]. If a process has locked a semaphore and then terminates, the semaphore retains its current value: all other processes waiting on the semaphore will still be waiting, and any new processes that access the semaphore will wait as well. In short, if a process holding a semaphore dies, you have to manually unlock it. For signals that the process intends to handle, you can always disable them before taking the lock and reenable them after releasing it. Or, you can install signal handlers in each process that ensure everything is properly cleaned up when the signal is delivered. Which solution is right depends on what you're doing. For signals you don't intend to handle (SIGSEGV) or cannot handle (SIGKILL) there's not much you can do. It's potentially dangerous to continue on after a child has received such a signal, so the right solution may be to literally do nothing and let the deadlock occur. If you must do cleanup, it must be done carefully. The key thing to understand is that the problems with killing threads haven't gone away: delivering the please die message isn't the hard part; it's safely cleaning up the thread in such a way it doesn't break the rest of the application! This problem still exists if you replace threads with processes (assuming you're using shared memory). As such, the better thing to do, if possible, is to avoid shared memory and use constructs like pipes and sockets for I/O. They have much better defined failure semantics, and do allow you a modicum of fault isolation. At the very least, graceful shutdown is much easier. HTH, Adam [1] For SIGINT from the terminal, the right thing /might/ happen. Strong emphasis on the might. -- http://mail.python.org/mailman/listinfo/python-list
Re: Interrput a thread
On Jan 3, 5:24 pm, Jean-Paul Calderone calderone.jeanp...@gmail.com wrote: Of course. The whole point here is not about threads vs processes. It's about shared memory concurrency vs non-shared memory concurrency. You can implement both with threads and both with processes, but threads are geared towards shared memory and processes are geared towards non-shared memory. So what most people mean by use processes is don't use shared memory. This is entirely my presumption, but I think if the OP were keenly aware of the differences between thread and processes, it's pretty likely he wouldn't have asked his question in the first place. Also, I've written lots and lots of use processes code on multiple platforms, and much of it has used some sort of shared memory construct. It's actually pretty common, especially in code bases with a lot of history. Not all the world is Apache. Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: Interrput a thread
On Jan 3, 6:17 pm, Adam Skutt ask...@gmail.com wrote: On Jan 3, 5:24 pm, Jean-Paul Calderone calderone.jeanp...@gmail.com wrote: Of course. The whole point here is not about threads vs processes. It's about shared memory concurrency vs non-shared memory concurrency. You can implement both with threads and both with processes, but threads are geared towards shared memory and processes are geared towards non-shared memory. So what most people mean by use processes is don't use shared memory. This is entirely my presumption, but I think if the OP were keenly aware of the differences between thread and processes, it's pretty likely he wouldn't have asked his question in the first place. Fair enough. :) Also, I've written lots and lots of use processes code on multiple platforms, and much of it has used some sort of shared memory construct. It's actually pretty common, especially in code bases with a lot of history. Not all the world is Apache. Hee hee, Apache. :) Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: Interrput a thread
On 31 Dic 2010, 23:25, Alice Bevan–McGregor al...@gothcandy.com wrote: On 2010-12-31 10:28:26 -0800, John Nagle said: Even worse, sending control-C to a multi-thread program is unreliable in CPython. See http://blip.tv/file/2232410; for why. It's painful. AFIK, that has been resolved in Python 3.2 with the introduction of an intelligent thread scheduler as part of the GIL release/acquire process. - Alice. Ok, but then suppose I have multiple long running threads that I want to delete/suspend because they are tooking too much time, which solution do you propose? Thanks, Mattia -- http://mail.python.org/mailman/listinfo/python-list
Re: Interrput a thread
gervaz ger...@gmail.com wrote: Ok, but then suppose I have multiple long running threads that I want to delete/suspend because they are tooking too much time, which solution do you propose? The right solution is to write your threads so they have an escape hatch -- to periodically check a should I die? flag, and then commit suicide. That is the ONLY clean way to handle this problem. There is simply no clean way to force another thread to die without its permission. -- Tim Roberts, t...@probo.com Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Interrput a thread
On 12/29/2010 3:31 PM, gervaz wrote: Hi all, I need to stop a threaded (using CTR+C or kill) application if it runs too much or if I decide to resume the work later. I come up with the following test implementation but I wanted some suggestion from you on how I can implement what I need in a better or more pythonic way. You can't send signals to individual threads under CPython. Even where the OS supports it, CPython does not. See http://docs.python.org/library/signal.html; Nor can you kill a thread. All you can do is ask it nicely to stop itself. Even worse, sending control-C to a multi-thread program is unreliable in CPython. See http://blip.tv/file/2232410; for why. It's painful. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Interrput a thread
On 2010-12-31 10:28:26 -0800, John Nagle said: Even worse, sending control-C to a multi-thread program is unreliable in CPython. See http://blip.tv/file/2232410; for why. It's painful. AFIK, that has been resolved in Python 3.2 with the introduction of an intelligent thread scheduler as part of the GIL release/acquire process. - Alice. -- http://mail.python.org/mailman/listinfo/python-list
Interrput a thread
Hi all, I need to stop a threaded (using CTR+C or kill) application if
it runs too much or if I decide to resume the work later.
I come up with the following test implementation but I wanted some
suggestion from you on how I can implement what I need in a better or
more pythonic way. Here the code:
import os
import signal
import time
from threading import Thread, current_thread
from queue import LifoQueue, Empty
COMMAND = {STOP: 0, NORMAL: 1}
THREAD_NUM = 5
lq = LifoQueue()
print({0}\n.format(os.getpid()))
class InterceptInterrupt(Exception):
pass
class Handler:
def __init__(self, queue):
self._queue = queue
def __del__(self):
print(Bye bye!)
def getHandler(self, signum, frame):
print(Interrupt raised!)
for _ in range(THREAD_NUM):
self._queue.put((COMMAND[STOP], None))
raise InterceptInterrupt
h = Handler(lq)
signal.signal(signal.SIGINT, h.getHandler)
for i in range(25):
lq.put((COMMAND[NORMAL], i))
def do_work(queue):
while True:
time.sleep(5)
try:
cmd, value = queue.get(block=False)
if cmd == COMMAND[STOP]:
print({0}: STOP command
received!.format(current_thread().name))
break
elif cmd == COMMAND[NORMAL]:
print(value)
except Empty:
break
threads = [Thread(target=do_work, args=(lq,)) for _ in
range(THREAD_NUM)]
for t in threads:
t.start()
while not lq.empty():
try:
time.sleep(1)
except (IOError, InterceptInterrupt):
break
for t in threads:
t.join()
if lq.empty():
print(The queue is empty.)
else:
print(The queue is NOT empty. Some additional work has to be
done.)
Thank you,
Mattia
--
http://mail.python.org/mailman/listinfo/python-list
