On 9/4/07, Jean-Paul Calderone <exarkun@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.