16.03.2011 12:43, Tomer Filiba kirjoitti:
alex, i thought we were past that discussion already:
http://groups.google.com/forum/#!searchin/rpyc/BgServingThread$20/rpyc/ECW63lMMPso/r_gCmcyZCXsJ
<http://groups.google.com/forum/#%21searchin/rpyc/BgServingThread$20/rpyc/ECW63lMMPso/r_gCmcyZCXsJ>
http://groups.google.com/forum/#!searchin/rpyc/starvation/rpyc/ejt5VDoKZDk/cNAj5dcDfQYJ
<http://groups.google.com/forum/#%21searchin/rpyc/starvation/rpyc/ejt5VDoKZDk/cNAj5dcDfQYJ>
http://groups.google.com/forum/#!searchin/rpyc/threads/rpyc/Aa0LiHKIlqE/qcMuum9w70AJ
<http://groups.google.com/forum/#%21searchin/rpyc/threads/rpyc/Aa0LiHKIlqE/qcMuum9w70AJ>
I never quite understood why there's a separate, optional BgServingThread.
In my opinion, such a thread should implicitly start with each
Connection and would be responsible for all communication with the
remote interpreter. Synchronous calls would just be queued and the
protocol thread would execute them first chance it gets. PEP 3148
Futures are the perfect match for this situation.
An NCO and a Gentleman
2011/3/16 Alex Grönholm <[email protected]
<mailto:[email protected]>>
16.03.2011 08:05, Fruch kirjoitti:
Maybe you can use asyncore, like pushy is doing.
select is better way to to networking (and not a timed loop)
Timed loop? Seriously? I hadn't even looked at BgServingThread,
but now it seems one might be warranted.
