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]> wrote: > ---------- Forwarded message ---------- > From: <[email protected]> > Date: Tue, Jun 11, 2013 at 2:30 AM > Subject: Can't post to rpyc user group. > To: [email protected] > > > 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]. > 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.
