I embedded an Rpyc threaded server in a preexistent daemon (an irc
bot), this is actually very simple;
start_threaded_server(port = DEFAULT_PORT)
then I had the necessity to stop the thread which accept() new
connections without killing the whole app, the thread is simply a while
True that spawn a new thread which serves each connection, so I placed
a flag and a break in this way:
def local_threaded_server(port = DEFAULT_PORT, **kw):
global stop
sock = create_listener_socket(port)
while True:
newsock, name = sock.accept()
t = Thread(target = serve_socket, args = (newsock,),
kwargs = kw)
t.setDaemon(True)
t.start()
if stop: break
but, since sock.accept() blocks, when I set stop=True the server wait
one more connection and only then stops.
I tried sock.settimeout(10) before entering the while and so checking
timeout exception on accept() but I experienced a strange behavior, the
clients connections close immediatly, with one of these exceptions on
the client side on their first use of the rpc connection:
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "C:\Programmi\Python24\lib\site-packages\Rpyc\NetProxy.py", line
82, in __repr__
return self.__request__("handle_repr", *args)
File "C:\Programmi\Python24\lib\site-packages\Rpyc\NetProxy.py", line
113, in __request__
return _get_conn(self).sync_request(handler, _get_oid(self), *args)
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Connection.py",
line 143, in sync_request
self.serve()
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Connection.py",
line 126, in serve
type, seq, data = self.channel.recv()
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Channel.py", line
50, in recv
type, seq, length = struct.unpack(self.HEADER_FORMAT,
self.stream.read(self.HEADER_SIZE))
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Stream.py", line
44, in read
buf = self.sock.recv(count)
socket.error: (10053, 'Software caused connection abort')
OR
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "C:\Programmi\Python24\lib\site-packages\Rpyc\NetProxy.py", line
82, in __repr__
return self.__request__("handle_repr", *args)
File "C:\Programmi\Python24\lib\site-packages\Rpyc\NetProxy.py", line
113, in __request__
return _get_conn(self).sync_request(handler, _get_oid(self), *args)
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Connection.py",
line 143, in sync_request
self.serve()
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Connection.py",
line 126, in serve
type, seq, data = self.channel.recv()
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Channel.py", line
50, in recv
type, seq, length = struct.unpack(self.HEADER_FORMAT,
self.stream.read(self.HEADER_SIZE))
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Stream.py", line
46, in read
raise EOFError()
EOFError
I'm not an expert in socket programming, but I can't see the
correlation between the "listener socket" being in timeout mode and a
different behavior the other sockets..
Anyhow the main goal is being able to shut down the thread of the rpyc
server, any other way is an appreciated suggestion.
--
http://mail.python.org/mailman/listinfo/python-list
