Thanks for the clarification. I erroneously assumed that blocking stuff was ok in Twisted as long as it happens before any communication. But it makes good sense that one should avoid this anywhere in a Twisted program.
Regards, Thomas 2009/3/26 Martin Geisler <m...@daimi.au.dk>: > Thomas P Jakobsen <thomas....@gmail.com> writes: > >> By the way, the same thing seem sto happen if the protocol, insted of >> asking the user to press enter, does some local computations like >> quering a database, sleeping, computing primes or the like. [...] > > Right -- callback functions *cannot block*! They must always returns > very quickly and use some asynchronous mechanism to signal when a > long-running operations is finished. See this FAQ: > > http://twistedmatrix.com/trac/wiki/FrequentlyAskedQuestions#HowdoIuseDeferredstomakemyblockingcodenon-blocking > > Twisted has a database abstraction layer that does this for databases: > > http://twistedmatrix.com/projects/core/documentation/howto/rdbms.html > > And a threadpool for more general tasks: > > http://twistedmatrix.com/projects/core/documentation/howto/threading.html > > For non-blocking access to stdin and stdout there is the > twisted.internet.stdio module, see: > > http://twistedmatrix.com/trac/browser/trunk/doc/core/examples/stdiodemo.py > > This means that your example should look similar to this: > > > > -- > Martin Geisler > > VIFF (Virtual Ideal Functionality Framework) brings easy and efficient > SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. > > _______________________________________________ > viff-devel mailing list (http://viff.dk/) > viff-devel@viff.dk > http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk > > _______________________________________________ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
