2011/5/5 Mark Hammond <mhamm...@skippinet.com.au>: > [re-added the mailing list - please keep everything there] > Sorry, my fault > On 4/05/2011 6:09 PM, Michael Illgner wrote: >> >> 2011/5/4 Mark Hammond<mhamm...@skippinet.com.au>: >>> > The question is more about the object xyz.xyz - if it is marked in the > registry and either free-threading or "both", then you can arrange to set > sys.coinit_flags=0 (which is COINIT_MULTITHREADED), you should be good to go > - the objects can probably be used across threads without complication. > > The threads do force some complication - the com_object can't be used on any > other thread directly - you must pass it to a different thread via > pythoncom.CoMarshalInterThreadInterfaceInStream - you will probably need to > search for samples. I believe that depending on the threading model, the > object returned will either marshal back the main thread or just make the > call directly on the new thread depending on all the threading models > involved. > I just took a look at the registry, the InprocServer32 key of my COM component has an entry ThreadingModel with value "both". So I if create the COM objects in the main thread and the socket server starts a new thread for every incoming request (socketserver.ThreadingMixIn) and the request handler uses pythoncom.CoInitialize/CoUninitialize for every request I should be on the right side ? This seems to work, but should I expect memory leaks, dangling handles etc. ?
> pythoncom.PumpMessages() or a loop using pythoncom.PumpWaitingMessages is > all you need. However, that will be complicated in your model, as the main > thread will be in the TCP server's listen loop. You probably need the > creation of the server to be in its own thread, which would be dedicates to > the listen and spawning new threads for handlers. > Ok, I will start the server_forever() loop in a separate thread, this should be simple ;-) >>> If you want every object to wind up calling the same "handler", then >>> yeah, >>> you would have your event handler delegate to some other singleton. >>> >> My handler needs some configuration data like an inet adress to send >> data back to the client, my first idea was to pass this data to the >> constructor / __init__ method, but i can use a kind of static or >> global configuration data object for this purpose too. > > So in effect you are just "broadcasting" on the tcp-server in response to > the COM events? I expect you will wind up needing a queue per connection, > with each COM event sticking stuff in the queue and the tcp handlers reading > from one. yes, the COM object send some status events during their lifetime, not directly related to other COM calls. The python event handler just collects the data for an event and sends them to another server using a socket. regards Michael _______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
