i always tried to avoid using threads in the library and just be thread-safe for users who wanted to share the connection... i wanted the connection to be just like a file object -- a passive object that the user operates externally. but the more i think about it, i think this model just doesn't fit. the connection simply isn't passive -- it carries out things on its own.
and because the thread issues have been with us for the past two years, i begin to like the idea of a background IO thread... maybe there's no escaping it. the only question then becomes -- do we want to force the user to have a background thread per connection? even if a connection is not shared by different threads? it's true they would be idle most of the time, but are threads cheap enough? on the other hand, that would open the door to asyncore or twisted integrations... it could be threaded by default, but the user could easily layer it on top of a reactor. i'll need more time to think about that... any suggestions/ideas would be appreciated. An NCO and a Gentleman 2011/3/16 Alex Grönholm <[email protected]> > 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/#!searchin/rpyc/starvation/rpyc/ejt5VDoKZDk/cNAj5dcDfQYJ > > http://groups.google.com/forum/#!searchin/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]> > >> 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. >> > > >
