The application is a WxPython client/server setup that has multiple clients connect to the server and engaging in duplex networking protocol.

I've had Twisted hooked up with AMP in the past, but it did not fully cut it for the architecture in the application without overly complicating things in the end.

So for the server I have got SocketServer with the ThreadingMixIn set up. At the moment I am working on the buffer/command queue for the server, but that's not the issue.

On the client side I can do all the normal sending of data, triggered by events in the UI, without too much problems. I am currently stuck trying to get the client to listen for responses without blocking the entire application. So I want to put this in a thread, but should it start at the part that's now commented out or should it be handled completely different and I am just not seeing it?

In short: I want the client to send commands to the server and listen for any responses without blocking/stalling the entire application.

The code below is prototyping code, please excuse any typical mistakes such as magical values and other hardcoded data, it will be different in the final code.

2 Answers
2

I think you're mistaken about whether a single-threaded or multi-threaded approach will complicate your application more or less. The problem you're wrestling with now is one of the many that (for example) Twisted solves for you out of the box.

The most common complaint people have about Twisted is that it makes them structure their code strangely, in a way they're not used to. However, when you're using a GUI library like wxPython, you have already accepted this constraint. Twisted's event-driven architecture is exactly like the event-driven architecture of all the popular GUI toolkits. As long as you keep using wxPython, also using Twisted isn't going to force you to do anything else you don't want to do.

On the other hand, switching to threads will mean you need to be very careful about access to shared data structures, you won't be able to unit test effectively, and many problems that arise will only do so when someone else is running your application - because they have a different number of cores than you, or their network has different latency characteristics, or any of a number of other things which cause your threaded code to run in ways you never experienced. With extreme care you can still write something that works, but it will be much more difficult.

Since you haven't posted any of your Twisted-based code here, I can't really give any specific advice on how to keep things as simple as possible. However, I recommend that you take another look at a non-threaded solution. Join the twisted-python@twistedmatrix.com mailing list, hop on #twisted on freenode, or post more stackoverflow questions about it. Lots of people will be eager to help. :)

Hi Jean-Paul, we actually have spoken in the past about the code I was working on. I had Twisted in the code base to handle the networking and asynchronous aspects, but in the end the code became unwieldly in both maintenance and ease to explain to others. Added to that is the fact that I need to introduce some barrier as a synchronisation point, something which you about a year or so ago said would become problematic with Twisted in the mix. Given I have already completely removed Twisted from the code base I am continuing down this lane with threading. Thanks for the offer of help though.
–
asmodaiApr 19 '11 at 12:03