On Fri, Nov 13, 2009 at 10:25 AM, <exarkun@twistedmatrix.com> wrote:
On 02:52 pm, landreville@deadtreepages.com wrote:
I am making a SOAP server and all (or at least the vast majority) will be returning a deferred. The whole SOAP method is encapsulated in a deferred in most of my cases (I havent implemented this part yet.) Then I got the idea that twisted.web.soap could just wrap my SOAP method (retrieved with lookupFunction) in a deferred and return that deferred right away.
For instance I would change twisted.web.soap.render where it says d = defer.maybeDeferred to d = threads.deferToThread
It sounds like you're conflating Deferreds and threads a little bit.
The reason Twisted doesn't use deferToThread on any method it calls by default is that threads are a really bummer. You have to worry about thread safety, you generally lose repeatability and determinism, your unit tests become a lot harder to write, if it's still possible to write them at all. Then there are the performance considerations. There are many kinds of code that CPython threads don't make any faster (and many kinds which it makes slower).
On the other hand, sometimes you really do want to do your work in a thread. That's why deferToThread exists, after all - to make your life a little bit simpler when those cases do arise. :)
What is it that you're going to be doing in these SOAP methods?
Jean-Paul
They are doing a bunch of setting and retrieving information from databases. There are a couple that load more modules which add more SOAP methods for interacting with a different database. None of the calls depend on eachother, so I don't want/need any of them to block the application from processing the next soap call. Is there other ways of generating deferreds without threads that I haven't seen?