16.03.2011 14:30, Tomer Filiba kirjoitti:
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?
RPyC is a bidirectional protocol by its nature, is it not? Then you need
a thread to answer the requests coming from the other side. Sharing the
communication channel between threads (as it is done now) is obviously
problematic.
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.
You haven't yet commented on mine.
An NCO and a Gentleman
2011/3/16 Alex Grönholm <[email protected]
<mailto:[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/#%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.
