Re: KeyboardInterrupt close failed in file object destructor: sys.excepthook is missing lost sys.stderr
On 19/11/2013 15:35, Jai wrote: Code # #!/usr/bin/env python import sys, re def find_position(line): pun = if re.search(r[.?!]+, line): pun = re.search(r[.?!]+, line).group() pos = line.find(pun) pos = pos+len(pun)-1 return pos def sentence_splitter(filename): f = open(filename, r) for line in f: line = line.strip() print line + \n while line: pos = find_position(line) line2 = line[ : pos+1].split( ) length = len(line2) last_word = line2[length -1] try: if re.search(r[A-Z]+.*, last_word) or line[pos+1] != or line[pos+2].islower() : print line[:pos+1], line = line[pos+1:] else: print line[ : pos+1] line = line[pos+1 :] except : print error here!! f.close() return bye bye if __name__==__main__: print sentence_splitter(sys.argv[1]) ##3 exicution python sentence_splitter6.py README | more ### README Mr. Smith bought example.cheapsite.com for 1.5 million dollars, i.e. he paid a lot for it. Did he mind? Adam Jones Jr. thinks he didn't. In any case, this isn't true... Well, with a probability of .9 it isn't. The result should be: ~ output Mr. Smith bought example.cheapsite.com for 1.5 million dollars, i.e. he paid a lot for it. Did he mind? Adam Jones Jr. thinks he didn't. In any case, this isn't true... Well, with a probability of .9 it isn't. The result should be: Mr. Smith bought example. cheapsite. com for 1. 5 million dollars, i. e. he paid a lot for it. Did he mind? Adam Jones Jr. thinks he didn't. In any case, this isn't true... Well, with a probability of . 9 it isn't. ##3 error KeyboardInterrupt close failed in file object destructor: sys.excepthook is missing lost sys.stderr ## please help what is this i have try lot but unable to remove it Please help us to help you by stating your OS and Python versions. Remove that dreadful bare exception which is masking everything in the try block that could possibly go wrong, rerun your code and see what happens. If you get a traceback display all of it for us to see via cut and paste, don't paraphrase. Finally the obligatory request for google users, would you please read and action this https://wiki.python.org/moin/GoogleGroupsPython to prevent us seeing potential double line spacing, thanks. -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt close failed in file object destructor: sys.excepthook is missing lost sys.stderr
MOn Tue, Nov 19, 2013 at 10:35 AM, Jai jaiprakashsingh...@gmail.com wrote: please help what is this i have try lot but unable to remove it Your code is getting into an infinite loop. One problem is, I suspect: def find_position(line): pun = if re.search(r[.?!]+, line): pun = re.search(r[.?!]+, line).group() pos = line.find(pun) pos = pos+len(pun)-1 return pos When your search fails, this function will return 0. Fix that. In general your problem isn't well defined enough for me to make sense of your algorithm. Can you show sample input and output? Can you describe the algorithm in plain English? -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt
Il Thu, 10 Dec 2009 04:56:33 +, Brad Harms ha scritto: On Thu, 10 Dec 2009 00:29:45 +, mattia wrote: Il Wed, 09 Dec 2009 16:19:24 -0800, Jon Clements ha scritto: On Dec 9, 11:53 pm, mattia ger...@gmail.com wrote: Hi all, can you provide me a simple code snippet to interrupt the execution of my program catching the KeyboardInterrupt signal? Thanks, Mattia Errr, normally you can just catch the KeyboardInterrupt exception -- is that what you mean? Jon. Ouch, so the simplest solution is just insert in the 'main' function a try/catch? I believed there was the necessity to create a signal and than attach the KeyboardInterrupt to it... KeyboardInterrupt is just an exception that gets raised when CTLR+C (or the OS's equivalent keyboard combo) gets pressed. It can occur at any point in a script since you never know when the user will press it, which is why you put the try: except KeyboardInterrupt: around as much of your script as possible. The signal that the OS sends to the Python interpreter is irrelevant. Ok, so can you tell me why this simple script doesn't work (i.e. I'm not able to catch the keyboard interrupt)? import time import sys from threading import Thread def do_work(): for _ in range(1000): try: time.sleep(1) print(., end=) sys.stdout.flush() except KeyboardInterrupt: sys.exit() def go(): threads = [Thread(target=do_work, args=()) for _ in range(2)] for t in threads: t.start() for t in threads: t.join() go() -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt
On Thu, Dec 10, 2009 at 4:42 PM, mattia ger...@gmail.com wrote: def go(): threads = [Thread(target=do_work, args=()) for _ in range(2)] for t in threads: t.start() for t in threads: t.join() The KeyboardInterrupt goes to the main thread, which is sitting there in t.join() with no exception handler around it. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC http://stutzbachenterprises.com -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt
mattia wrote: Il Thu, 10 Dec 2009 04:56:33 +, Brad Harms ha scritto: On Thu, 10 Dec 2009 00:29:45 +, mattia wrote: Il Wed, 09 Dec 2009 16:19:24 -0800, Jon Clements ha scritto: On Dec 9, 11:53 pm, mattia ger...@gmail.com wrote: Hi all, can you provide me a simple code snippet to interrupt the execution of my program catching the KeyboardInterrupt signal? Thanks, Mattia Errr, normally you can just catch the KeyboardInterrupt exception -- is that what you mean? Jon. Ouch, so the simplest solution is just insert in the 'main' function a try/catch? I believed there was the necessity to create a signal and than attach the KeyboardInterrupt to it... KeyboardInterrupt is just an exception that gets raised when CTLR+C (or the OS's equivalent keyboard combo) gets pressed. It can occur at any point in a script since you never know when the user will press it, which is why you put the try: except KeyboardInterrupt: around as much of your script as possible. The signal that the OS sends to the Python interpreter is irrelevant. Ok, so can you tell me why this simple script doesn't work (i.e. I'm not able to catch the keyboard interrupt)? import time import sys from threading import Thread def do_work(): for _ in range(1000): try: time.sleep(1) print(., end=) sys.stdout.flush() except KeyboardInterrupt: sys.exit() def go(): threads = [Thread(target=do_work, args=()) for _ in range(2)] for t in threads: t.start() for t in threads: t.join() go() Only the main thread can receive the keyboard interrupt. -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt
Il Thu, 10 Dec 2009 23:10:02 +, Matthew Barnett ha scritto: mattia wrote: Il Thu, 10 Dec 2009 04:56:33 +, Brad Harms ha scritto: On Thu, 10 Dec 2009 00:29:45 +, mattia wrote: Il Wed, 09 Dec 2009 16:19:24 -0800, Jon Clements ha scritto: On Dec 9, 11:53 pm, mattia ger...@gmail.com wrote: Hi all, can you provide me a simple code snippet to interrupt the execution of my program catching the KeyboardInterrupt signal? Thanks, Mattia Errr, normally you can just catch the KeyboardInterrupt exception -- is that what you mean? Jon. Ouch, so the simplest solution is just insert in the 'main' function a try/catch? I believed there was the necessity to create a signal and than attach the KeyboardInterrupt to it... KeyboardInterrupt is just an exception that gets raised when CTLR+C (or the OS's equivalent keyboard combo) gets pressed. It can occur at any point in a script since you never know when the user will press it, which is why you put the try: except KeyboardInterrupt: around as much of your script as possible. The signal that the OS sends to the Python interpreter is irrelevant. Ok, so can you tell me why this simple script doesn't work (i.e. I'm not able to catch the keyboard interrupt)? import time import sys from threading import Thread def do_work(): for _ in range(1000): try: time.sleep(1) print(., end=) sys.stdout.flush() except KeyboardInterrupt: sys.exit() def go(): threads = [Thread(target=do_work, args=()) for _ in range(2)] for t in threads: t.start() for t in threads: t.join() go() Only the main thread can receive the keyboard interrupt. Ok, so is there any way to stop all the threads if the keyboard interrupt is received? -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt
On Dec 9, 11:53 pm, mattia ger...@gmail.com wrote: Hi all, can you provide me a simple code snippet to interrupt the execution of my program catching the KeyboardInterrupt signal? Thanks, Mattia Errr, normally you can just catch the KeyboardInterrupt exception -- is that what you mean? Jon. -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt
Il Wed, 09 Dec 2009 16:19:24 -0800, Jon Clements ha scritto: On Dec 9, 11:53 pm, mattia ger...@gmail.com wrote: Hi all, can you provide me a simple code snippet to interrupt the execution of my program catching the KeyboardInterrupt signal? Thanks, Mattia Errr, normally you can just catch the KeyboardInterrupt exception -- is that what you mean? Jon. Ouch, so the simplest solution is just insert in the 'main' function a try/catch? I believed there was the necessity to create a signal and than attach the KeyboardInterrupt to it... -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt
On 12/11/2009 10:43 AM, mattia wrote:
Ok, so is there any way to stop all the threads if the keyboard interrupt
is received?
You can't stop a thread from outside. The thread has to end itself (by
ending the function). Usually, in the thread, you will check the value
of a variable. If it's false, then it's time to stop and head to the end
of the function.
# global, or better use a Quit sentinel in a Queue
import time, sys
from threading import Thread
running = True
def do_work():
while True:
time.sleep(1)
print(., end=)
sys.stdout.flush()
if running == False:
break
print('thread ended')
def go():
global running
threads = [Thread(target=do_work, args=()) for _ in range(2)]
for t in threads:
t.start()
try:
while running:
time.sleep(1)
running = any(t.is_alive() for t in threads)
except KeyboardInterrupt:
running = False
--
http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt
En Thu, 10 Dec 2009 20:43:48 -0300, mattia ger...@gmail.com escribió: Il Thu, 10 Dec 2009 23:10:02 +, Matthew Barnett ha scritto: Only the main thread can receive the keyboard interrupt. Ok, so is there any way to stop all the threads if the keyboard interrupt is received? If all other threads (except the main one) are daemon threads, then the whole process finishes when the main thread exits; all daemon threads are abruptly finished. Note that try/finally blocks are not honored, neither are with statements... If you want an orderly retreat, the other threads must cooperate (e.g. the main thread sets a flag and they periodically check for it). -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt
On Thu, 10 Dec 2009 00:29:45 +, mattia wrote: Il Wed, 09 Dec 2009 16:19:24 -0800, Jon Clements ha scritto: On Dec 9, 11:53 pm, mattia ger...@gmail.com wrote: Hi all, can you provide me a simple code snippet to interrupt the execution of my program catching the KeyboardInterrupt signal? Thanks, Mattia Errr, normally you can just catch the KeyboardInterrupt exception -- is that what you mean? Jon. Ouch, so the simplest solution is just insert in the 'main' function a try/catch? I believed there was the necessity to create a signal and than attach the KeyboardInterrupt to it... KeyboardInterrupt is just an exception that gets raised when CTLR+C (or the OS's equivalent keyboard combo) gets pressed. It can occur at any point in a script since you never know when the user will press it, which is why you put the try: except KeyboardInterrupt: around as much of your script as possible. The signal that the OS sends to the Python interpreter is irrelevant. -- Brad Harms -- http://alphaios.net -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt eats my error and then won't be caught
On Jun 20, 2009, at 10:21 PM, greg wrote: Philip Semanchuk wrote: Best of all, PyErr_CheckSignals() doesn't interfere with a Python- level signal handler if one is set. Ah, I hadn't realised that you were doing this in C code, and I was trying to think of a Python-level solution. For C code, the solution you give sounds like a good one. My only misgiving is that the user might expect to get a KeyboardInterrupt in response to Ctrl-C, so it might be better to just let it propagate instead of turning it into a different exception. I completely agree. The simple solution (for me) is to handle all return codes of EINTR the same way which is to raise posix_ipc.Error with the message The wait was interrupted by a signal. But that loses information. KeyboardInterrupt is very specific while posix_ipc.Error is generic and even parsing the message doesn't tell much more. When my C code sees EINTR, I will probably raise KeyboardError when I see that and add a specific posix_ipc.SignalError to raise in other EINTR circumstances. Thanks, Philip -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt eats my error and then won't be caught
greg g...@cosc.canterbury.ac.nz (g) wrote: g Philip Semanchuk wrote: try: sem.acquire() # User hits Ctrl + C while this is waiting except: print * I caught it! Instead a KeyboardInterrupt error is propagated up to the interpreter and the process is killed as if the try/except wasn't there at all. g Not sure exactly what's happening, but I think I can guess. g Python installs a signal handler for Ctrl-C that sets a g flag in the interpreter. Every so many bytecodes executed, g the flag is checked and KeyboardInterrupt raised if it's g set. g So there can be a short delay between the Ctrl-C signal g being received and KeyboardInterrupt being raised, and it g seems that this delay results in it happening after the g try-except has exited. I think you are approaching the cause of the problem. Your answer triggered the following thought in my head: There are actually two exceptions occurring: One is the Ctrl-C, which as you correctly say, will probably delayed until there is a `check' in the interpreter (see also David Beazley's wonderful presentation on the GIL). The other one is the exception that is generated in the IPC code by returning a NULL. This one should caught by the except clause. As the call to sem.acquire releases and reacquires the GIL, I think signal processing will be done immediately. This causes the KeyboardInterrupt exception to occur immediately i.e. to interrupt the handling of the other exception. g You could try using signal.signal() to install a handler g for Ctrl-C that does nothing in a section around the g sem.acquire call(). That should prevent the KeyboardInterrupt g flag from being set, but the signal will still be occurring g at the Unix level, so the system call will get interrupted. Your suggestion seems to work: import posix_ipc import signal sem = posix_ipc.Semaphore(None, posix_ipc.O_CREX) signal.signal(signal.SIGINT, lambda sig, frame: None) status = [] try: status.append(Trying) sem.acquire() # User hits Ctrl + C while this is waiting status.append(Acquired) except: status.append(I caught it!) print status sem.close() sem.unlink() prints: ['Trying', 'I caught it!'] I also tried some other variants, catching the KeyboardInterrupt at various places: This one prints: ['Trying', 'Keyboard Interrupt'] This suggests to me that the first exception handling is aborted by the Ctrl-C handling. import posix_ipc sem = posix_ipc.Semaphore(None, posix_ipc.O_CREX) status = [] try: try: status.append(Trying) sem.acquire() # User hits Ctrl + C while this is waiting status.append(Acquired) except: status.append(I caught it!) except KeyboardInterrupt: status.append(Keyboard Interrupt) print status sem.close() sem.unlink() And this one prints: ['Trying', 'I caught it!'] import posix_ipc sem = posix_ipc.Semaphore(None, posix_ipc.O_CREX) status = [] try: status.append(Trying) try: sem.acquire() # User hits Ctrl + C while this is waiting status.append(Acquired) except KeyboardInterrupt: status.append(Interrupt) except: status.append(I caught it!) print status sem.close() sem.unlink() I was actually a bit surprised that the addition of the try/except KeyboardInterrupt helps solve the problem but that apparently the exception handler is not executed. Folding the two try's into one with two except clauses will not help as there are indeed two exceptions to be handled. I also added traceback printout in the outer exception handler and it points to the sem.acquire line. My conclusion is that if there are two exceptions at the same time, the inner exception handler is interrupted by the other exception even before the except clause can be entered. And only the outer one is really executed. This explains the behaviour that the OP described. I think you can only have two exceptions at the same time if at least one of them is a signal. -- Piet van Oostrum p...@cs.uu.nl URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4] Private email: p...@vanoostrum.org -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt eats my error and then won't be caught
After my previous experiment I was curious how this works with input(). I replaced the sem.acquire() with raw_input() and ran the same tests. Now the inner exception is really taken so it works like the OP expected. The exception, however is KeyboardInterrupt, not the special exception from the IPC module. So I looked in the source code how they did it: The code is in Parser/myreadline.c. This code for input in function calls PyErr_CheckSignals() and PyOS_InterruptOccurred() for a proper handling of the interrupt. So it seems the OP should do something similar. Onl;y to deliver the custom error you will have to do some other stuff. I don't know what but maybe calling PyErr_SetString is sufficient as it might overwrite the KeyboardInterrupt stuff. -- Piet van Oostrum p...@cs.uu.nl URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4] Private email: p...@vanoostrum.org -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt eats my error and then won't be caught
On Jun 20, 2009, at 7:41 AM, Piet van Oostrum wrote: After my previous experiment I was curious how this works with input(). I replaced the sem.acquire() with raw_input() and ran the same tests. Now the inner exception is really taken so it works like the OP expected. The exception, however is KeyboardInterrupt, not the special exception from the IPC module. So I looked in the source code how they did it: The code is in Parser/myreadline.c. This code for input in function calls PyErr_CheckSignals() and PyOS_InterruptOccurred() for a proper handling of the interrupt. So it seems the OP should do something similar. Onl;y to deliver the custom error you will have to do some other stuff. I don't know what but maybe calling PyErr_SetString is sufficient as it might overwrite the KeyboardInterrupt stuff. Thank you Greg and especially Piet for going to the trouble of installing posix_ipc and experimenting with it. Piet, your research into raw_input() gave me a solution. In my C code, I added a call to PyErr_CheckSignals() as the first line inside the case EINTR. Apparently calling PyErr_CheckSignals() sets the Python error indicator -- PyErr_Occurred() returns true and the error is PyExc_KeyboardInterrupt. I'm able to clear that error and return my own. Prior to adding the call to PyErr_CheckSignals(), PyErr_Occurred() returned false, so my code had no error to clear. Best of all, PyErr_CheckSignals() doesn't interfere with a Python- level signal handler if one is set. This worked under OS X and Linux. I'll have to think some more about exactly how I want my module to report the Ctrl-C, but at least now I have the tools to control the situation. Thanks again for your invaluable assistance. If I'm ever in NL or NZ I'll buy you a beer. =) Cheers Philip -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt eats my error and then won't be caught
Philip Semanchuk wrote: Best of all, PyErr_CheckSignals() doesn't interfere with a Python- level signal handler if one is set. Ah, I hadn't realised that you were doing this in C code, and I was trying to think of a Python-level solution. For C code, the solution you give sounds like a good one. My only misgiving is that the user might expect to get a KeyboardInterrupt in response to Ctrl-C, so it might be better to just let it propagate instead of turning it into a different exception. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt eats my error and then won't be caught
Philip Semanchuk wrote: try: sem.acquire() # User hits Ctrl + C while this is waiting except: print * I caught it! Instead a KeyboardInterrupt error is propagated up to the interpreter and the process is killed as if the try/except wasn't there at all. Not sure exactly what's happening, but I think I can guess. Python installs a signal handler for Ctrl-C that sets a flag in the interpreter. Every so many bytecodes executed, the flag is checked and KeyboardInterrupt raised if it's set. So there can be a short delay between the Ctrl-C signal being received and KeyboardInterrupt being raised, and it seems that this delay results in it happening after the try-except has exited. You could try using signal.signal() to install a handler for Ctrl-C that does nothing in a section around the sem.acquire call(). That should prevent the KeyboardInterrupt flag from being set, but the signal will still be occurring at the Unix level, so the system call will get interrupted. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt catch does not shut down the socketserver
Gabriel Genellina wrote: En Sat, 16 May 2009 04:04:03 -0300, Igor Katson descent...@gmail.com escribió: Gabriel Genellina wrote: En Fri, 15 May 2009 09:04:05 -0300, Igor Katson escribió: Lawrence D'Oliveiro wrote: In message mailman.185.1242375959.8015.python-l...@python.org, Igor Katson wrote: Lawrence D'Oliveiro wrote: In message mailman.183.1242371089.8015.python-l...@python.org, Igor Katson wrote: I have problems in getting a SocketServer to shutdown. Shutdown implies closing the listening socket, doesn't it? No (perhaps it should, but that is another issue). There is a documentation bug; BaseServer.shutdown is documented as Tells the serve_forever() loop to stop and waits until it does. [1] The docstring is much more explicit: Stops the serve_forever loop. Blocks until the loop has finished. This must be called while serve_forever() is running in another thread, or it will deadlock. So, if you have a single-threaded server, *don't* use shutdown(). And, to orderly close the listening socket, use server_close() instead. Your Hmm. Gabriel, could you please show the same for the threaded version? This one deadlocks: [code removed] The shutdown method should *only* be called while serve_forever is running. If called after server_forever exited, shutdown() blocks forever. [code removed] But, what are you after, exactly? I think I'd use the above code only in a GUI application with a background server. There are other alternatives, like asyncore or Twisted. For now, I am just using server.server_close() and it works. The server itself is an external transaction manager for PostgreSQL, when a client connects to it, serialized data interchange beetween the server and the client starts, e.g. first the client sends data, then the server sends data, then again the client, then the server and so on. I haven't used asyncore or Twisted yet, and didn't know about their possible usage while writing the project. I'll research in that direction. -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt catch does not shut down the socketserver
Gabriel Genellina wrote:
En Fri, 15 May 2009 09:04:05 -0300, Igor Katson escribió:
Lawrence D'Oliveiro wrote:
In message mailman.185.1242375959.8015.python-l...@python.org,
Igor Katson wrote:
Lawrence D'Oliveiro wrote:
In message mailman.183.1242371089.8015.python-l...@python.org,
Igor Katson wrote:
I have problems in getting a SocketServer to shutdown.
Do you want to do a shutdown or a close?
I want the server close the socket ...
You want to do a close, do a close, not a shutdown
http://docs.python.org/library/socket.html.
Shutdown implies closing the listening socket, doesn't it?
No (perhaps it should, but that is another issue). There is a
documentation bug; BaseServer.shutdown is documented as Tells the
serve_forever() loop to stop and waits until it does. [1]
The docstring is much more explicit: Stops the serve_forever loop.
Blocks until the loop has finished. This must be called while
serve_forever() is running in another thread, or it will deadlock.
So, if you have a single-threaded server, *don't* use shutdown(). And, to
orderly close the listening socket, use server_close() instead. Your code
would become:
from SocketServer import TCPServer, BaseRequestHandler
server = TCPServer(('localhost',1234), BaseRequestHandler)
try:
server.serve_forever()
except KeyboardInterrupt:
print ^C detected
pass
finally:
print server_close()
server.server_close()
print bye
(I've opened http://bugs.python.org/issue6031 )
[1]
http://docs.python.org/dev/library/socketserver.html?highlight=baseserver#SocketServer.BaseServer.shutdown
Thanks, Gabriel, that's exactly what I was waiting for.
--
http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt catch does not shut down the socketserver
Gabriel Genellina wrote:
En Fri, 15 May 2009 09:04:05 -0300, Igor Katson escribió:
Lawrence D'Oliveiro wrote:
In message mailman.185.1242375959.8015.python-l...@python.org,
Igor Katson wrote:
Lawrence D'Oliveiro wrote:
In message mailman.183.1242371089.8015.python-l...@python.org,
Igor Katson wrote:
I have problems in getting a SocketServer to shutdown.
Do you want to do a shutdown or a close?
I want the server close the socket ...
You want to do a close, do a close, not a shutdown
http://docs.python.org/library/socket.html.
Shutdown implies closing the listening socket, doesn't it?
No (perhaps it should, but that is another issue). There is a
documentation bug; BaseServer.shutdown is documented as Tells the
serve_forever() loop to stop and waits until it does. [1]
The docstring is much more explicit: Stops the serve_forever loop.
Blocks until the loop has finished. This must be called while
serve_forever() is running in another thread, or it will deadlock.
So, if you have a single-threaded server, *don't* use shutdown(). And, to
orderly close the listening socket, use server_close() instead. Your code
would become:
from SocketServer import TCPServer, BaseRequestHandler
server = TCPServer(('localhost',1234), BaseRequestHandler)
try:
server.serve_forever()
except KeyboardInterrupt:
print ^C detected
pass
finally:
print server_close()
server.server_close()
print bye
(I've opened http://bugs.python.org/issue6031 )
[1]
http://docs.python.org/dev/library/socketserver.html?highlight=baseserver#SocketServer.BaseServer.shutdown
Hmm. Gabriel, could you please show the same for the threaded version?
This one deadlocks:
from SocketServer import TCPServer, BaseRequestHandler
from threading import Thread
server = TCPServer(('localhost',1234), BaseRequestHandler)
try:
run_thread = Thread(target=server.serve_forever)
run_thread.start()
run_thread.join()
except KeyboardInterrupt:
print ^C detected
pass
finally:
print server_shutdown()
kill_thread = Thread(target=server.shutdown)
kill_thread.start()
print bye
--
http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt catch does not shut down the socketserver
En Sat, 16 May 2009 04:04:03 -0300, Igor Katson descent...@gmail.com
escribió:
Gabriel Genellina wrote:
En Fri, 15 May 2009 09:04:05 -0300, Igor Katson escribió:
Lawrence D'Oliveiro wrote:
In message mailman.185.1242375959.8015.python-l...@python.org, Igor
Katson wrote:
Lawrence D'Oliveiro wrote:
In message mailman.183.1242371089.8015.python-l...@python.org,
Igor Katson wrote:
I have problems in getting a SocketServer to shutdown.
Shutdown implies closing the listening socket, doesn't it?
No (perhaps it should, but that is another issue). There is a
documentation bug; BaseServer.shutdown is documented as Tells the
serve_forever() loop to stop and waits until it does. [1]
The docstring is much more explicit: Stops the serve_forever loop.
Blocks until the loop has finished. This must be called while
serve_forever() is running in another thread, or it will deadlock.
So, if you have a single-threaded server, *don't* use shutdown(). And,
to orderly close the listening socket, use server_close() instead. Your
Hmm. Gabriel, could you please show the same for the threaded version?
This one deadlocks:
[code removed]
The shutdown method should *only* be called while serve_forever is
running. If called after server_forever exited, shutdown() blocks forever.
code
from SocketServer import TCPServer, BaseRequestHandler
from threading import Thread
server = TCPServer(('localhost',1234), BaseRequestHandler)
run_thread = Thread(target=server.serve_forever)
run_thread.start()
try:
print press ^C to exit
import time; time.sleep(30)
except KeyboardInterrupt:
print ^C detected
pass
server.shutdown()
run_thread.join()
print bye
/code
But, what are you after, exactly? I think I'd use the above code only in a
GUI application with a background server.
There are other alternatives, like asyncore or Twisted.
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt catch does not shut down the socketserver
In message mailman.183.1242371089.8015.python-l...@python.org, Igor Katson wrote: I have problems in getting a SocketServer to shutdown. Do you want to do a shutdown or a close? -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt catch does not shut down the socketserver
Lawrence D'Oliveiro wrote: In message mailman.183.1242371089.8015.python-l...@python.org, Igor Katson wrote: I have problems in getting a SocketServer to shutdown. Do you want to do a shutdown or a close? I want the server close the socket, and the program to continue after that (in this case, just to terminate). -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt catch does not shut down the socketserver
In message mailman.185.1242375959.8015.python-l...@python.org, Igor Katson wrote: Lawrence D'Oliveiro wrote: In message mailman.183.1242371089.8015.python-l...@python.org, Igor Katson wrote: I have problems in getting a SocketServer to shutdown. Do you want to do a shutdown or a close? I want the server close the socket ... You want to do a close, do a close, not a shutdown http://docs.python.org/library/socket.html. -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt catch does not shut down the socketserver
Lawrence D'Oliveiro wrote: In message mailman.185.1242375959.8015.python-l...@python.org, Igor Katson wrote: Lawrence D'Oliveiro wrote: In message mailman.183.1242371089.8015.python-l...@python.org, Igor Katson wrote: I have problems in getting a SocketServer to shutdown. Do you want to do a shutdown or a close? I want the server close the socket ... You want to do a close, do a close, not a shutdown http://docs.python.org/library/socket.html. Shutdown implies closing the listening socket, doesn't it? -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt catch does not shut down the socketserver
En Fri, 15 May 2009 09:04:05 -0300, Igor Katson escribió:
Lawrence D'Oliveiro wrote:
In message mailman.185.1242375959.8015.python-l...@python.org, Igor
Katson wrote:
Lawrence D'Oliveiro wrote:
In message mailman.183.1242371089.8015.python-l...@python.org, Igor
Katson wrote:
I have problems in getting a SocketServer to shutdown.
Do you want to do a shutdown or a close?
I want the server close the socket ...
You want to do a close, do a close, not a shutdown
http://docs.python.org/library/socket.html.
Shutdown implies closing the listening socket, doesn't it?
No (perhaps it should, but that is another issue). There is a
documentation bug; BaseServer.shutdown is documented as Tells the
serve_forever() loop to stop and waits until it does. [1]
The docstring is much more explicit: Stops the serve_forever loop.
Blocks until the loop has finished. This must be called while
serve_forever() is running in another thread, or it will deadlock.
So, if you have a single-threaded server, *don't* use shutdown(). And, to
orderly close the listening socket, use server_close() instead. Your code
would become:
from SocketServer import TCPServer, BaseRequestHandler
server = TCPServer(('localhost',1234), BaseRequestHandler)
try:
server.serve_forever()
except KeyboardInterrupt:
print ^C detected
pass
finally:
print server_close()
server.server_close()
print bye
(I've opened http://bugs.python.org/issue6031 )
[1]
http://docs.python.org/dev/library/socketserver.html?highlight=baseserver#SocketServer.BaseServer.shutdown
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt should not kill subprocess
In article [EMAIL PROTECTED], Michael Goerz [EMAIL PROTECTED] wrote: But as it seems, a keyboard interrupt will automatically pass down to the subprocesses, causing them to abort. Is there a way that I can prevent the subprocesses from being canceled by a keyboard interrupt? You might try posix.setsid(), from the child fork. The object is to get the child fork out of the foreground process group for the Berkeley terminal driver. This defines who gets signals, when they originate in terminal control keys. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt not caught
why is KeyboardInterrupt not caught (xp)? import sys try: inp = sys.stdin.read() except (KeyboardInterrupt, SystemExit): print kbd-interr,SystemExit except EOFError: print eof encountered except: print caught all self.showtraceback() print normal end result after script startet and ^C hit: ctrl_test.py normal end Traceback (most recent call last): File C:\work\py_src\ctrl_test.py, line 11, in ? print normal end KeyboardInterrupt Hi, are you sure this is exactly what you run? The code above works perfectly for me and prints kbd-interr,SystemExit normal end as it should upon pressing Ctrl-C (although I'm on linux not xp but that shouldn't matter at all). -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt not caught
En Fri, 16 Feb 2007 06:58:54 -0300, Daniel Nogradi [EMAIL PROTECTED] escribió: why is KeyboardInterrupt not caught (xp)? Hi, are you sure this is exactly what you run? The code above works perfectly for me and prints kbd-interr,SystemExit normal end as it should upon pressing Ctrl-C (although I'm on linux not xp but that shouldn't matter at all). I'm using XP and it works as expected too. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt not caught
On Fri, 16 Feb 2007 01:47:43 -0800, ruka_at_ wrote: Hi, why is KeyboardInterrupt not caught (xp)? import sys try: inp = sys.stdin.read() except (KeyboardInterrupt, SystemExit): print kbd-interr,SystemExit except EOFError: print eof encountered I don't think you ever get an EOFError from stdin. If you type ^D immediately, stdin.read() returns an empty string. except: print caught all self.showtraceback() I don't imagine you'll get any other exceptions either. Not that it matters, but what's self? print normal end result after script startet and ^C hit: ctrl_test.py normal end Traceback (most recent call last): File C:\work\py_src\ctrl_test.py, line 11, in ? print normal end KeyboardInterrupt It works as expected for me. I seem to have a vague recollection that the keyboard interrupt under Windows isn't ^C but something else... ^Z maybe? -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt not caught
En Fri, 16 Feb 2007 07:26:09 -0300, Steven D'Aprano [EMAIL PROTECTED] escribió: I seem to have a vague recollection that the keyboard interrupt under Windows isn't ^C but something else... ^Z maybe? Ctrl-C is the keyboard interrupt, Ctrl-Z means EOF. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt not caught
On 16 Feb., 11:44, Gabriel Genellina [EMAIL PROTECTED] wrote: Thanks to all of you, for the fast answers. The code I showed you is actually the code running. I tried to catch eof, cause I read ^C could produce EOF (the self.showtraceback() was just a stupid cut 'n paste). But not even the except that should catch all exceptions is triggered. Thanks again, br Rudi -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt not caught
On 16 Feb., 12:16, [EMAIL PROTECTED] wrote: On 16 Feb., 11:44, Gabriel Genellina [EMAIL PROTECTED] wrote: I've tried it in cygwin, result: $ python.exe c:/work/py_src/ctrl_test.py kbd-interr,SystemExit normal end br Rudi -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt from syscalls
Fredrik Tolf wrote: So how does it work? Does my code get to return Py_FALSE, and the interpreter ignores it, seeing that an exception is set? Is a non-local exit performed right over my call stack (in which case my next question would be how to clean up resources being used from my C code)? Or does something completely else happen? the signal handler adds an entry to a pending calls queue, which is checked by the interpreter at regular intervals. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt from syscalls
On Wed, 2006-11-22 at 19:45 +0100, Fredrik Lundh wrote: Fredrik Tolf wrote: So how does it work? Does my code get to return Py_FALSE, and the interpreter ignores it, seeing that an exception is set? Is a non-local exit performed right over my call stack (in which case my next question would be how to clean up resources being used from my C code)? Or does something completely else happen? the signal handler adds an entry to a pending calls queue, which is checked by the interpreter at regular intervals. I see. So if I get that right, that would mean that if I, in my function, would loop and retry when getting an EINTR instead of returning, a KeyboardInterrupt from e.g. Ctrl-C would be delayed until it has other reason to return? Thanks for your answer! Fredrik Tolf -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt vs extension written in C
Tamas Nepusz [EMAIL PROTECTED] writes on 20 Oct 2005 15:39:54 -0700: The library I'm working on is designed for performing calculations on large-scale graphs (~1 nodes and edges). I want to create a Python interface for that library, so what I want to accomplish is that I could just type from igraph import * in a Python command line and then access all of the functionalities of the igraph library. Now it works, except the fact that if, for example, I start computing the diameter of a random graph of ~10 nodes and ~20 edges, I can't cancel it, because the KeyboardInterrupt is not propagated to the Python toplevel (or it isn't even generated until the igraph library routine returns). Python installs a SIGINT handler that just notes that such a signal was received. The note is handled during bytecode execution. This way, Python handles the (dangerous) asynchronous signal synchronously (which is much safer). But, it also means that a signal during execution of your C extension is only handled when it finished. What you can do in your wrapper code: Temporarily install a new handler for SIGINT that uses longjmp to quit the C extension execution when the signal occurs. Note that longjmp is dangerous. Great care is necessary. It is likely that SIGINT occurrences will lead to big resource leaks (because your C extension will have no way to release resources when it gets quit with longjmp). Dieter -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt vs extension written in C
On 22 Oct 2005 22:02:46 +0200, Dieter Maurer [EMAIL PROTECTED] wrote: Tamas Nepusz [EMAIL PROTECTED] writes on 20 Oct 2005 15:39:54 -0700: The library I'm working on is designed for performing calculations on large-scale graphs (~1 nodes and edges). I want to create a Python interface for that library, so what I want to accomplish is that I could just type from igraph import * in a Python command line and then access all of the functionalities of the igraph library. Now it works, except the fact that if, for example, I start computing the diameter of a random graph of ~10 nodes and ~20 edges, I can't cancel it, because the KeyboardInterrupt is not propagated to the Python toplevel (or it isn't even generated until the igraph library routine returns). Python installs a SIGINT handler that just notes that such a signal was received. The note is handled during bytecode execution. This way, Python handles the (dangerous) asynchronous signal synchronously (which is much safer). But, it also means that a signal during execution of your C extension is only handled when it finished. What you can do in your wrapper code: Temporarily install a new handler for SIGINT that uses longjmp to quit the C extension execution when the signal occurs. Note that longjmp is dangerous. Great care is necessary. It is likely that SIGINT occurrences will lead to big resource leaks (because your C extension will have no way to release resources when it gets quit with longjmp). Note that swapcontext() is probably preferable to longjmp() in almost all circumstances. In cases where it isn't, siglongjmp() definitely is. Jp -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt vs extension written in C
Tamas Nepusz wrote: Hi everyone, I have tried to do some googling before asking my question here, but I haven't found any suitable answer. I am developing a Python API for a graph library written in pure C. The library is doing an awful lot of math computations, and some of them can take a pretty long time (depending on the size of the input). If I invoke such calculation from Python using my own extension, the interpreter locks until the calculation is complete (I mean, it is not responding to Ctrl-C or SIGINT). My question is: is there any way to allow the user to use Ctrl-C to generate a KeyboardInterrupt and cancel such large computations? I'm assuming that although pressing Ctrl-C may generate a KeyboardInterrupt in Python, it is not propagated to the user level until the call into the graph library returns. I tried to add Py_BEGIN_ALLOW_THREADS before the call to the underlying C library and Py_END_ALLOW_THREADS after returning from it, but I had no luck. I'm not especially an expert with C-extensions. So I'm not sure if I can be of any help here. But if what you really are after is only terminating the whole program (instead of just the computation, and then continue), you might consider threads. Do the calls in a separate thread, and make that a daemon-thread. Then things _should_ work as expected, as the main thread will receive the signal. Hopefully... if your call releases the GIL. Which Py_*_ALLOW_THREADS seems to do. So - give it a try :) Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt vs extension written in C
No, that's actually a bit more complicated. The library I'm working on is designed for performing calculations on large-scale graphs (~1 nodes and edges). I want to create a Python interface for that library, so what I want to accomplish is that I could just type from igraph import * in a Python command line and then access all of the functionalities of the igraph library. Now it works, except the fact that if, for example, I start computing the diameter of a random graph of ~10 nodes and ~20 edges, I can't cancel it, because the KeyboardInterrupt is not propagated to the Python toplevel (or it isn't even generated until the igraph library routine returns). I would like to allow the user to cancel the computation with the usual Ctrl-C and return to the Python interactive interface. This whole feature is not vital, but it would mean a big step towards user-friendliness. I have access to the source code of igraph as well (since one of my colleagues is developing it), so another possible solution would be to inject some calls into the igraph source code which temporarily cancels the computation and checks whether there's something waiting in the Python interpreter, but I haven't found any function in the API which allows me to do this. Tamas -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt vs extension written in C
Quoth Tamas Nepusz [EMAIL PROTECTED]: | No, that's actually a bit more complicated. The library I'm working on | is designed for performing calculations on large-scale graphs (~1 | nodes and edges). I want to create a Python interface for that library, | so what I want to accomplish is that I could just type from igraph | import * in a Python command line and then access all of the | functionalities of the igraph library. Now it works, except the fact | that if, for example, I start computing the diameter of a random graph | of ~10 nodes and ~20 edges, I can't cancel it, because the | KeyboardInterrupt is not propagated to the Python toplevel (or it isn't | even generated until the igraph library routine returns). I would like | to allow the user to cancel the computation with the usual Ctrl-C and | return to the Python interactive interface. | This whole feature is not vital, but it would mean a big step towards | user-friendliness. | I have access to the source code of igraph as well (since one of my | colleagues is developing it), so another possible solution would be to | inject some calls into the igraph source code which temporarily cancels | the computation and checks whether there's something waiting in the | Python interpreter, but I haven't found any function in the API which | allows me to do this. Hm, tough question. Even in C, this would be a little awkward. If you only wanted the program to abort on ^C, then you could just replace the default sigint handler with SIG_DFL. But then you'd be back to the shell prompt, not the python prompt. If you want to catch the signal, but also abort a computation, then as you say, the computation needs to check periodically. Rather than peek into Python for this, I'm wondering if your module could set its own signal handler for SIGINT, which would set a library flag. Then call PyErr_SetInterrupt(), to emulate the normal signal handler. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt being lost?
Operation Latte Thunder wrote: I have a simple test proggie that isn't behaving like I expect ( found below ). The script will infinitely run ( as expected ), but seems to completely ignore control-C's. Shouldn't the interpreter pass along KeyboardInterrupts and break out of the while loop, or am I missing something? Using python 2.4.2 on linux ( if it matters ) -- Script Below -- import threading, traceback, time class TestThread ( threading.Thread ): def __init__ ( self ): threading.Thread.__init__ ( self ) def run ( self ): print Starting... while True: time.sleep ( 1 ) return if __name__ == '__main__': test = TestThread ( ) test.start() print Started... test.join() -- chris Chris, Thread.join() is implemented using a lock, and the acquisition of a lock is uninterruptible. (See http://docs.python.org/lib/module-thread.html) Therefore, your main thread will block until the other thread terminates or the process is forcibly killed. Even if it could be interrupted, I don't think there's any way to raise that exception in the other thread. (Python's threading support leaves something to be desired when compared to, say, Java.) -- David -- http://mail.python.org/mailman/listinfo/python-list
