[Twisted-Python] reactor.stop() won't, threads and Queue to blame?

Glyph Lefkowitz glyph at divmod.com
Mon Oct 25 11:32:02 MDT 2004


On Mon, 2004-10-25 at 12:41 -0400, Brett Viren wrote:

> In this case the Deferred is used as a return value for Twisted's
> XML-RPC server implementation.  I go to this trouble of a CommandQueue
> because my system blurs the distinction between server and client and
> this was leading to deadlocks.  This CommandQueue should make sure
> that all the troublesome communications are atomic.

Doing things in threads almost always makes things *less* atomic than
just leaving them all in the main reactor thread.  Even if I'm totally
mistaken, I feel like I have to ask a few questions to make sure that
newbies don't stumble across this thread in the future and think they
need to start managing their own threadpools so Twisted won't
deadlock ;)

When you say you're "blurring the distinction between server and
client", do you mean you're implementing something like an XMLRPC proxy,
where the server is itself a client, relaying requests elswhere and
waiting for their results?  Or something else?

Were you running requests in threads before you came up with the
CommandQueue abstraction?  If not, what caused the deadlocks?  How was
the client/server blurring related to the deadlocks?

Finally, did you consider an approach where, rather than queueing
commands, you just executed them synchronously and let the reactor
serialize them?  If so, what lead to the decision to change to a
thread-based approach?





More information about the Twisted-Python mailing list