[Twisted-Python] Wrapping a Perspective Broker remote object with a blocking API

Jean-Paul Calderone exarkun at divmod.com
Tue Sep 4 10:08:28 MDT 2007


On Tue, 4 Sep 2007 09:38:12 -0600, Brian Granger <ellisonbg.net at gmail.com> wrote:
>> I'm not sure why you're trying to do this at all, instead of just using
>> Twisted in a single-threaded manner.
>>
>
>This is a usage case that we run into regularly.  We have a lot of PB
>based servers, but sometimes people want to use a client to them from
>an interactive Python or IPython prompt.  At that point you have to
>run the reactor in a different thread.

Not true, in fact.  See twisted/conch/stdio.py, for example.  I don't know
what the Twisted/IPython integration code ended up looking like (or if it
was ever taken to a satisfactory "completion" point) but I don't think it
is necessary to have multiple threads for that use case, either.

>But, I have never seen a
>method of putting a blocking API on top of such a client that was
>_really_ thread safe.  I have seen a few approaches that seem to work,
>but that are clearly non-thread safe.  I would love to see a robust
>solution for this problem though - one that could be fully trusted.

Why isn't a solution based on Twisted's thread-safe event-posting API 
(reactor.callFromThread) and the thread-safe event-posting API of whatever
other thing is being integrated with "really" thread-safe?  Sure, you can
write programs which will deadlock as a result of application-level bugs
where one thread is blocked on a request and the other thread needs some
information from it before the request can be satisfied, but this is inherent
to wanting to drive an asynchronous API synchronously.  Aside from it, I
don't think there are any problems with what I described above.

Jean-Paul




More information about the Twisted-Python mailing list