design choice: multi-threaded / asynchronous wxpython client?

[Bjoern Schliessmann]

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