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