bullockbefriending bard wrote: > 1) The data for the race about to start updates every (say) 15 > seconds, and the data for earlier and later races updates only > every > (say) 5 minutes. There is no point for me to be hammering the > server with requests every 15 seconds for data for races after the > upcoming race... I should query for this perhaps every 150s to be > safe. But for the upcoming race, I must not miss any updates and > should query every > ~7s to be safe. So... in the middle of a race meeting the > situation might be:
I don't fully understand this, but can't you design the server in a way that you can connect to it and it notifies you about important things? IMHO, polling isn't ideal. > My initial thought was to have two threads for the different > update polling cycles. In addition I would probably need another > thread to handle UI stuff, and perhaps another for dealing with > file/DB data write out. No need for any additional threads. UI, networking and file I/O can operate asynchronously. Using wxPython's timers with callback functions, you should need only standard Python modules (except wx). > But, I wonder if using Twisted is a better idea? IMHO that's only advisable if you like to create own protocols and reuse them in different apps, or need full-featured customisable implementations of advanced protocols. Additionally, you'd *have to* use multiple threads: One for the Twisted event loop and one for the wxPython one. There is a wxreactor in Twisted which integrates the wxPython event loop, but I stopped using it due to strange deadlock problems which began with some wxPython version. Also, it seems it's no more in development. But my alternative works perfectly (main thread with Twisted, and a GUI thread for wxPython, communicating over Python standard queues). You'd only need additional threads if you would do heavy number crunching inside the wxPython or Twisted thread. For the respective event loop not to hang, it's advisable to use a separate thread for long-running calculations. > I have zero experience with these kinds of design choices and > would be very happy if those with experience could point out the > pros and cons of each (synchronous/multithreaded, or Twisted) for > dealing with the two differing sample rates problem outlined > above. I'd favor "as few threads as neccessary" approach. In my experience this saves pain (i. e. deadlocks and boilerplate queueing code). Regards, Björn -- BOFH excuse #27: radiosity depletion -- http://mail.python.org/mailman/listinfo/python-list