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