I'm using an XMLRPC server under Windows.
What I wonder is how I could create a server, that can be killed with CTRL-C
The server aborts easily with CTRL-BREAK but not with CTRL-C (under Windows)
If I press CTRL-C it will only abort when the next RPC call occurs.
It seems it is blocking in the select() call in the handle_request()
function.
Is there any trick, which I overlook?
thanks in advance for ideas and bye
N
> I'm using an XMLRPC server under Windows.
>
> What I wonder is how I could create a server, that can be killed with
> CTRL-C
>
> The server aborts easily with CTRL-BREAK but not with CTRL-C (under
> Windows)
>
> If I press CTRL-C it will only abort when the next RPC call occurs.
> It seems it is blocking in the select() call in the handle_request()
> function.
Python 2.6 and up behaves exactly as you want.
On previous versions you may use this:
class MyXMLRPCServer(SimpleXMLRPCServer.SimpleXMLRPCServer):
... your methods ...
if not hasattr(SimpleXMLRPCServer.SimpleXMLRPCServer, 'shutdown'):
# pre 2.6
quit = False
def serve_forever(self):
while not self.quit:
self.handle_request()
def shutdown(self):
self.quit = True
def server_bind(self):
self.socket.settimeout(1.0)
SimpleXMLRPCServer.SimpleXMLRPCServer.server_bind(self)
--
Gabriel Genellina
Gabriel Genellina wrote:
> En Fri, 05 Feb 2010 20:03:51 -0300, News123 <new...@free.fr> escribiᅵ:
>
>> I'm using an XMLRPC server under Windows.
>>
>> What I wonder is how I could create a server, that can be killed with
>> CTRL-C
>>
>> The server aborts easily with CTRL-BREAK but not with CTRL-C (under
>> Windows)
>>
>> If I press CTRL-C it will only abort when the next RPC call occurs.
>> It seems it is blocking in the select() call in the handle_request()
>> function.
>
> Python 2.6 and up behaves exactly as you want.
> On previous versions you may use this:]
I', using python 2.6.4 nd neither on Win-XP nor on Win-7 I'm capable to
abort with CTR-C ?
On Linux however I can use CTRL-C .
>
> class MyXMLRPCServer(SimpleXMLRPCServer.SimpleXMLRPCServer):
>
> ... your methods ...
>
> if not hasattr(SimpleXMLRPCServer.SimpleXMLRPCServer, 'shutdown'):
>
> # pre 2.6
> quit = False
>
> def serve_forever(self):
> while not self.quit:
> self.handle_request()
>
> def shutdown(self):
> self.quit = True
>
> def server_bind(self):
> self.socket.settimeout(1.0)
> SimpleXMLRPCServer.SimpleXMLRPCServer.server_bind(self)
>
I tried something similiar, but without setting the socket timeout.
I'll try it now with.
N
Overloading server_bind() with your version solved my problem.
thanks again
N
Strange. With Python 2.6.4 I don't need to do that; I'd say the difference
is in the OS or antivirus (some AV are known to break the TCP stack).
--
Gabriel Genellina
Perhaps, but I've also found that ctrl-C doesn't work on Windows.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"At Resolver we've found it useful to short-circuit any doubt and just
refer to comments in code as 'lies'. :-)"
I don't know if this is exactly the same, but FWIW ...
I had the following, in a test program -
from wsgiref.simple_server import make_server
myserver = MyServer()
httpd = make_server('', 7789, myserver)
httpd.serve_forever()
try:
while True:
sleep(1)
except KeyboardInterrupt:
httpd.shutdown()
I could not get it to respond to Ctrl-C.
Then I read somewhere that it must run in a separate thread, so I changed it
like this -
- httpd.serve_forever()
+ threading.Thread(target=httpd.serve_forever).start()
Now it does respond to Ctrl-C.
HTH
Frank Millman
That's probably it. It's more annoying for me because I run Windows with
a VM on a Mac, which doesn't have ctrl-break.
> In article <mailman.2422.1265961...@python.org>,
> Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:
>> On 11 Feb 2010 21:18:26 -0800, aa...@pythoncraft.com (Aahz) declaimed the
>> following in gmane.comp.python.general:
>>> In article <mailman.2077.1265524...@python.org>,
>>> Gabriel Genellina <gags...@yahoo.com.ar> wrote:
>>>>
>>>> Strange. With Python 2.6.4 I don't need to do that; I'd say the
>>>> difference
>>>> is in the OS or antivirus (some AV are known to break the TCP stack).
>>>
>>> Perhaps, but I've also found that ctrl-C doesn't work on Windows.
>>
>> Unless the running program makes an I/O call to the console, I don't
>> think <ctrl-c> gets past the device driver... <G>
>
> That's probably it. It's more annoying for me because I run Windows with
> a VM on a Mac, which doesn't have ctrl-break.
On a "real" PC with Windows XP SP3 and Python 2.6.4, with an idle server,
just hitting Ctrl-C was enough:
D:\temp>python -m SimpleXMLRPCServer
Running XML-RPC server on port 8000
Traceback (most recent call last):
File "d:\apps\python26\lib\runpy.py", line 122, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "d:\apps\python26\lib\runpy.py", line 34, in _run_code
exec code in run_globals
File "d:\apps\python26\lib\SimpleXMLRPCServer.py", line 615, in <module>
server.serve_forever()
File "d:\apps\python26\lib\SocketServer.py", line 224, in serve_forever
r, w, e = select.select([self], [], [], poll_interval)
KeyboardInterrupt
A slightly more realistic example: a busy, single threaded server. I had
to hit Ctrl-C twice: the first time, KeyboardInterrupt was sent as a Fault
response to the client.
import sys
def busy():
x = 50000
y = x**x
return "Ok"
if sys.argv[1]=='server':
import SimpleXMLRPCServer
server = SimpleXMLRPCServer.SimpleXMLRPCServer(("localhost",
8000),logRequests=False)
server.register_function(busy)
server.serve_forever()
else:
import xmlrpclib
proxy = xmlrpclib.ServerProxy("http://localhost:8000/")
while True:
print "client", proxy.busy()
Maybe the OP's code containes a bare 'except:' clause that swallows
KeyboardInterrupt, or the server is so busy that is always executing a
function handler (and all KeyboardInterrupt become Fault and are sent as a
function response).
Mmm, perhaps that's a bug, a KeyboardInterrupt should bubble up to the
server code, not being treated as an error in computing the function
result.
--
Gabriel Genellina
Overloading server_bind() makes the server killable with ctrl-C.
I noticed however, that I can't use this as solution.
If the bind function sets a time out, then it seems,
that there are regular small time windows, when connecting clients fail.
I don't have the error message any more, but will post it when I capture
the event next time.
bye
N