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

[Rasjid Wilcox]

On 9/4/07, Jean-Paul Calderone <exarkun at divmod.com> wrote:
> The example code doesn't do anything with Events, and I'm not sure I
> understand what you're describing above, so I don't know if that part
> of your code is correct or not.

>From simple-client.py

def wait_factory():
    "Returns a callback to apply to a deffered, and event to wait on"
    evt = threading.Event()
    def set_event(result):
        evt.set()
        return result
    return set_event, evt

> >I have not really looked into the thread safety issues yet, but have
> >been looking into reactor.callFromThread and whether it is required
> >here.
>
> Yes, it is.  As your code is now, it calls APIs which are not threadsafe
> from a non-reactor thread.  This isn't allowed and will definitely result
> in incorrect behavior sometimes.

I figured that was the case.  I was planning to fix this after getting
some feedback.  Which has been worthwhile, since I now know about
twisted.internet.blockingCallFromThread which would appear to do what
I want.

> >If the entire approach is inherently broken for some reason, I'd like
> >to know so I can look at alternatives.
>
> I'm not sure why you're trying to do this at all, instead of just using
> Twisted in a single-threaded manner.

Because the ultimate 'user' of the remote object will be a Visual Basic program.

My vision is as follows:
The Visual Basic program will talk to a python com server.
The python com server will run a PB client that will talk to a PB server.
The PB server will start a windows com component.
Everything gets relayed in a fairly transparent manner, and as far as
the VB program is concerned, it is just talking to a local com
component.

Standard DCOM does not really do what I want, since it assumes a
fairly fixed Client-Server model, whereas I want a peer-to-peer setup
where each node could be a client and a server.  PB would allow me to
do exactly that.

It might be possible to create a new twisted reactor that integrates
into the python com server event loop.  That would presumably be the
correct way to deal with this. But that would seem like far more work
that I have time to devote to this problem at this time.

So my question really is:
What are the problems / brawbacks with running the twisted reactor in
a non-main thread, provided all calls to the reactor are done through
twisted.internet.blockingCallFromThread?

Cheers,

Rasjid.