Saizan wrote:
> 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
First off, instead of the "while True" and the break, you could write:
while not stop:
> 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:
[snip]
> 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.
Now to the real issue. I've also had such weird problems with socket
timeout in Python. The best workaround I found is to use select() to
check for activity on the socket(s), and use select()'s timeout
mechanism. So far, this has worked without a hitch on both WindowsXP
and Solaris Sparc9 installations.
- Tal
reduce(lambda m,x:[m[i]+s[-1] for i,s in enumerate(sorted(m))],
[[chr(154-ord(c)) for c in '.&-&,l.Z95193+179-']]*18)[3]
--
http://mail.python.org/mailman/listinfo/python-list
