Hi, I've encountered a similar issue. I'm using ThreadedServer* *inside a C process. each time there a long call to C (i.e. a call that doesn't return for ~30sec) all the rest of the calls are held up in the queue for the same connection
You say TheardPoolServer. could fix my problem ? I'll need to try it one day (our current solution is smelly, all our "long" calls were waiting on a queue in C, we changed the timeout to wait on it to 0, and did it in a loop in a python thread in the rpyc client side) adding support for setting the stack size of those thread http://docs.python.org/2/library/thread.html#thread.stack_size could help control the memory foot print when many thread are needed On Tuesday, June 11, 2013 11:24:15 AM UTC+3, Oliver Drake wrote: > > Hi David, > Have you tried the ThreadPoolServer? > http://rpyc.readthedocs.org/en/latest/api/utils_server.html#rpyc.utils.server.ThreadPoolServer > Cheers, > Oliver > > > On 11 June 2013 19:35, Tomer Filiba <[email protected] <javascript:>>wrote: > >> ---------- Forwarded message ---------- >> From: <[email protected] <javascript:>> >> Date: Tue, Jun 11, 2013 at 2:30 AM >> Subject: Can't post to rpyc user group. >> To: [email protected] <javascript:> >> >> >> Hello, >> >> I know your RPyC page said not to contact you directly, but I seem to be >> unable to post to the rpyc user group. >> >> David E. West >> >> I wished to post the following: >> >> ---- >> Hello, >> >> First off, RPyC implements an amazing concept! >> >> My question has to do with concurrent access of these netref's. It >> appears that the protocol is designed to be used by only a single >> thread at a time. Below is an example of what I'm talking about: >> >> Server: >> ---- >> $ python -c 'import >> >> rpyc.utils.server;rpyc.utils.server.ThreadedServer(service=rpyc.SlaveService,port= >> 9001).start()' >> ---- >> >> Client: >> ---- >> $ python -c 'import time,rpyc,thread;c=rpyc.connect("127.0.0.1", 9001, >> >> rpyc.SlaveService);thread.start_new_thread(c.modules.time.sleep,(10,));print >> time.ctime();c.modules.time.time();print time.ctime()' >> Mon Jun 10 12:09:00 2013 >> Mon Jun 10 12:09:10 2013 >> ---- >> >> So we issue a remote time.sleep(10) in a background thread, and this >> blocks a remote time.time() in the foreground. >> >> Also, here is an example that uses rpyc.async instead of a thread. It >> suffers the same issue: >> >> ---- >> $ python -c 'import time,rpyc;c=rpyc.connect("127.0.0.1", 9001, >> >> rpyc.SlaveService);asleep=rpyc.async(c.modules.time.sleep);r=asleep(10);print >> time.ctime();c.modules.time.time();print time.ctime();print r.ready, >> r.value' >> Mon Jun 10 11:55:01 2013 >> Mon Jun 10 11:55:11 2013 >> True None >> ---- >> >> So even though we are issuing the remote time.sleep(10) via >> rpyc.async, the call to time.time() still blocks. >> >> Is this behavior by design? >> >> I can imagine that making the protocol concurrent would introduce the >> complexity of requiring some sort of thread pool on the remote side. >> Is it just a matter of trying to keep the rpyc implementation as >> simple as possible, or is there a design philosophy being imposed >> here? >> >> David E. West >> ---- >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "rpyc" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- --- You received this message because you are subscribed to the Google Groups "rpyc" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
