I'm building a Python API around a black box .NET DLL using Python .NET. The DLL is only doing networking operations. The DLL require me to run a windows message pumping loop, otherwise the network operations get stuck after a while. I run the windows message loop using System.Windows.Forms.Application.Run()
in the main thread. This works fine for only receiving data. My program starts to behave weirdly though when I start to do calls from an other Python thread to the DLL. I think it is related to threading since the problems are accuring very irregular - networking events disappear or come in very late. As far as I know Python and C# are thread safe, but maybe because of the multiple layers of wrapping something goes wrong.
So I have a couple of questions:
Is it a bad idea to do calls to the DLL's from multiple Python theads? Or does this depend on the DLL internals? I thought from the DLL's perspective the Python threads are seen as one single agents due to the GIL.
Does every Python thread using this DLL need a message pump?
It is probably a good idea to keep all DLL interactions in one thread. I have difficulties accomplishing this, since I give control to the message pump loop in the main thread. My naive approach would be to put new outgoing network messages generated in my worker thread on a Python queue, create a custom message pump loop in the main thread that does the windows event handling but also monitors my queue and if there is message would do a call to the DLL. But this all feels quite clunky and a lot of work for such a simple task. Is this the right approach?
Is there an other way to put a function in the main windows event loop that monitors the previously described queue and takes action? Or should I dive into the .NET specifics and start using .NET events or dispatchers?