From: Geoff T. <gta...@na...> - 2000-12-07 20:03:51
Attachments:
testthreads.py
|
I've identified a problem with Ctrl-C handling in ThreadedAppServer such that it can sometimes fail to shut down and needs to be killed. The reason is that Ctrl-C causes the main Python thread to immediately throw an exception, wherever it may be in the code. If you happen to press Ctrl-C while the main thread is blocking, waiting to put something into the request queue, then the queue gets into a state where it blocks indefinitely the next time you try to put something into the queue. Here's a test program that illustrates the problem. I've tried it on NT with Python 1.5.2. If I run it with argument 0, it never exits when I press Ctrl-C and has to be killed. But if I run it with argument 1, it works fine because it puts the Queue manipulation into a separate thread -- this would be a way to fix ThreadedAppServer. If someone could run it on Linux and let me know if you get the same results, I'd appreciate it. -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |
From: Tom S. <tom...@li...> - 2000-12-07 21:25:01
|
Geoff Talvola wrote: > > I've identified a problem with Ctrl-C handling in ThreadedAppServer such > that it can sometimes fail to shut down and needs to be killed. The > reason is that Ctrl-C causes the main Python thread to immediately throw > an exception, wherever it may be in the code. If you happen to press > Ctrl-C while the main thread is blocking, waiting to put something into > the request queue, then the queue gets into a state where it blocks > indefinitely the next time you try to put something into the queue. > > Here's a test program that illustrates the problem. I've tried it on NT > with Python 1.5.2. If I run it with argument 0, it never exits when I > press Ctrl-C and has to be killed. But if I run it with argument 1, it > works fine because it puts the Queue manipulation into a separate thread > -- this would be a way to fix ThreadedAppServer. > > If someone could run it on Linux and let me know if you get the same > results, I'd appreciate it. Under Linux I have to kill them in BOTH cases. Your prediction does not seem to work.. Exception in thread Thread-3: Traceback (innermost last): File "/usr/lib/python1.5/threading.py", line 376, in __bootstrap self.run() File "/usr/lib/python1.5/threading.py", line 364, in run apply(self.__target, self.__args, self.__kwargs) File "testthreads.py", line 8, in threadfunc time.sleep(1.0) IOError: [Errno 4] Unterbrechung während des Betriebssystemaufrufs Exception in thread Thread-4: Traceback (innermost last): File "/usr/lib/python1.5/threading.py", line 376, in __bootstrap self.run() File "/usr/lib/python1.5/threading.py", line 364, in run apply(self.__target, self.__args, self.__kwargs) File "testthreads.py", line 8, in threadfunc time.sleep(1.0) IOError: [Errno 4] Unterbrechung während des Betriebssystemaufrufs Ignore the German Error messages. ... Means "interrupt during system call" ... -- Tom Schwaller http://www.linux-community.de http://www.linux-magazin.de/ |
From: Geoff T. <gta...@na...> - 2000-12-07 21:48:36
|
It looks to me that on Linux, Ctrl-C can trigger an exception in ANY thread, not just the main thread. I think this might make it impossible to handle Ctrl-C safely in ThreadedAppServer on Linux. I've already developed a fix for Windows NT, but it might do no good on Linux. Should I check it in anyway? Tom Schwaller wrote: > Geoff Talvola wrote: > > > > I've identified a problem with Ctrl-C handling in ThreadedAppServer such > > that it can sometimes fail to shut down and needs to be killed. The > > reason is that Ctrl-C causes the main Python thread to immediately throw > > an exception, wherever it may be in the code. If you happen to press > > Ctrl-C while the main thread is blocking, waiting to put something into > > the request queue, then the queue gets into a state where it blocks > > indefinitely the next time you try to put something into the queue. > > > > Here's a test program that illustrates the problem. I've tried it on NT > > with Python 1.5.2. If I run it with argument 0, it never exits when I > > press Ctrl-C and has to be killed. But if I run it with argument 1, it > > works fine because it puts the Queue manipulation into a separate thread > > -- this would be a way to fix ThreadedAppServer. > > > > If someone could run it on Linux and let me know if you get the same > > results, I'd appreciate it. > > Under Linux I have to kill them in BOTH cases. Your > prediction does not seem to work.. > > Exception in thread Thread-3: > Traceback (innermost last): > File "/usr/lib/python1.5/threading.py", line 376, in __bootstrap > self.run() > File "/usr/lib/python1.5/threading.py", line 364, in run > apply(self.__target, self.__args, self.__kwargs) > File "testthreads.py", line 8, in threadfunc > time.sleep(1.0) > IOError: [Errno 4] Unterbrechung während des Betriebssystemaufrufs > > Exception in thread Thread-4: > Traceback (innermost last): > File "/usr/lib/python1.5/threading.py", line 376, in __bootstrap > self.run() > File "/usr/lib/python1.5/threading.py", line 364, in run > apply(self.__target, self.__args, self.__kwargs) > File "testthreads.py", line 8, in threadfunc > time.sleep(1.0) > IOError: [Errno 4] Unterbrechung während des Betriebssystemaufrufs > > Ignore the German Error messages. ... Means "interrupt during system > call" ... > > -- > > Tom Schwaller > http://www.linux-community.de > http://www.linux-magazin.de/ -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |
From: Tom S. <tom...@li...> - 2000-12-08 00:08:47
|
Geoff Talvola wrote: > > It looks to me that on Linux, Ctrl-C can trigger an exception in ANY thread, > not just the main thread. I think this might make it impossible to handle > Ctrl-C safely in ThreadedAppServer on Linux. > > I've already developed a fix for Windows NT, but it might do no good on > Linux. Should I check it in anyway? Maybe this is a good question for comp.lang.python ? -- Tom Schwaller http://www.linux-community.de http://www.linux-magazin.de/ |
From: Chuck E. <ec...@mi...> - 2000-12-08 00:37:00
|
I don't see any reason not to. If you could put the appropriate comment with it, that would be nice. Or, at your discretion if it's not too messy, only incur the change when os.name=='nt'. I agree with Tom that this would be appropriate for comp.lang.python. -Chuck At 04:51 PM 12/7/2000 -0500, Geoff Talvola wrote: >It looks to me that on Linux, Ctrl-C can trigger an exception in ANY thread, >not just the main thread. I think this might make it impossible to handle >Ctrl-C safely in ThreadedAppServer on Linux. > >I've already developed a fix for Windows NT, but it might do no good on >Linux. Should I check it in anyway? > >Tom Schwaller wrote: > > > Geoff Talvola wrote: > > > > > > I've identified a problem with Ctrl-C handling in ThreadedAppServer such > > > that it can sometimes fail to shut down and needs to be killed. The > > > reason is that Ctrl-C causes the main Python thread to immediately throw > > > an exception, wherever it may be in the code. If you happen to press > > > Ctrl-C while the main thread is blocking, waiting to put something into > > > the request queue, then the queue gets into a state where it blocks > > > indefinitely the next time you try to put something into the queue. > > > > > > Here's a test program that illustrates the problem. I've tried it on NT > > > with Python 1.5.2. If I run it with argument 0, it never exits when I > > > press Ctrl-C and has to be killed. But if I run it with argument 1, it > > > works fine because it puts the Queue manipulation into a separate thread > > > -- this would be a way to fix ThreadedAppServer. > > > > > > If someone could run it on Linux and let me know if you get the same > > > results, I'd appreciate it. > > > > Under Linux I have to kill them in BOTH cases. Your > > prediction does not seem to work.. > > > > Exception in thread Thread-3: > > Traceback (innermost last): > > File "/usr/lib/python1.5/threading.py", line 376, in __bootstrap > > self.run() > > File "/usr/lib/python1.5/threading.py", line 364, in run > > apply(self.__target, self.__args, self.__kwargs) > > File "testthreads.py", line 8, in threadfunc > > time.sleep(1.0) > > IOError: [Errno 4] Unterbrechung während des Betriebssystemaufrufs > > > > Exception in thread Thread-4: > > Traceback (innermost last): > > File "/usr/lib/python1.5/threading.py", line 376, in __bootstrap > > self.run() > > File "/usr/lib/python1.5/threading.py", line 364, in run > > apply(self.__target, self.__args, self.__kwargs) > > File "testthreads.py", line 8, in threadfunc > > time.sleep(1.0) > > IOError: [Errno 4] Unterbrechung während des Betriebssystemaufrufs > > > > Ignore the German Error messages. ... Means "interrupt during system > > call" ... > > > > -- > > > > Tom Schwaller > > http://www.linux-community.de > > http://www.linux-magazin.de/ > >-- > > >- Geoff Talvola > Parlance Corporation > gtalvola@NameConnector.com > >_______________________________________________ >Webware-discuss mailing list >Web...@li... >http://lists.sourceforge.net/mailman/listinfo/webware-discuss |
From: Dave <dwa...@de...> - 2000-12-08 01:47:02
|
Your test works exactly as you describe with Python 2.0 under Linux. With the thread (arg=1) it shuts down on Ctrl-C, without (arg=0) it hangs. It seems that this was the case with the AppServer early on in Webware development, but at some point the problem went away and I was able to shut Webware down with a Ctrl-C. I haven't been working with it alot lately but I haven't seen the problem. Dave. Geoff Talvola wrote: > I've identified a problem with Ctrl-C handling in ThreadedAppServer such > that it can sometimes fail to shut down and needs to be killed. The > reason is that Ctrl-C causes the main Python thread to immediately throw > an exception, wherever it may be in the code. If you happen to press > Ctrl-C while the main thread is blocking, waiting to put something into > the request queue, then the queue gets into a state where it blocks > indefinitely the next time you try to put something into the queue. > > Here's a test program that illustrates the problem. I've tried it on NT > with Python 1.5.2. If I run it with argument 0, it never exits when I > press Ctrl-C and has to be killed. But if I run it with argument 1, it > works fine because it puts the Queue manipulation into a separate thread > -- this would be a way to fix ThreadedAppServer. > > If someone could run it on Linux and let me know if you get the same > results, I'd appreciate it. > > -- > > > - Geoff Talvola > Parlance Corporation > gtalvola@NameConnector.com |
From: Geoff T. <gta...@na...> - 2000-12-08 01:54:27
|
Dave wrote: > Your test works exactly as you describe with Python 2.0 under Linux. > With the thread (arg=1) it shuts down on Ctrl-C, without (arg=0) it > hangs. It seems that this was the case with the AppServer early on in > Webware development, but at some point the problem went away and I was > able to shut Webware down with a Ctrl-C. I haven't been working with it > alot lately but I haven't seen the problem. > > Dave. Thanks for the data point. You're right, it used to _always_ hang on Ctrl-C, but that problem was fixed a while ago as you said. Recently, I was only getting the hang on Ctrl-C when the app server was backed up with requests. I wrote a test program that spawned 100 threads and had each thread use urlopen to fetch a servlet. This causes the request queue inside of ThreadedAppServer to fill up, and if you hit Ctrl-C at THAT point, it would hang. Basically, it looks to me that if your main thread is blocking in Queue.put when the queue is full, if you hit Ctrl-C at that point, the Queue will hang forever on the next put. Moving all the fancy Queue manipulation into a worker thread solved the problem. -- - Geoff Talvola Parlance Corporation gtalvola@NameConnector.com |