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
>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
>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?


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?