On Wed, 2003-10-22 at 16:53, Aubin Paul wrote: > Since a number of Freevo features take advantage of network > connections, but some of these connections can block the interface > depending on where they are, I've added support for timeoutsocket (for > Python 2.2) and Python 2.3 socket timeouts.
This is the wrong way to fix this kind of problem in general and likely specifically with Freevo. The UI "thread" of code should never make calls that could potentially block for long periods of time, like waiting for network sockets and the like. Probably the most popular solution to this kind of problem is to change the service to use a callback. Probably preaching to the choir here, but just in case... The UI should have a function (which we'll call "callback") that should be called when the blocking call finally does return (in the case of weather for instance, a function which should take the weather data and update the plugin's display), then calls a function (which we'll call "fetch_data") to fetch data and gives it the function to call (callback) when the data returns. This called function (fetch_data) should do it's work in the background and return control to the caller (i.e. the UI) immediately. Once the data is returned in the called function (fetch_data, which is in the background), it calls the callback function with the data which updates the screen display. No visible blockage to the user. As Freevo uses more and more external sources of data, this sort of thing is going to become more and more important, so setting up the framework for it early will be important. Aubin, maybe you want to pioneer this effort seeing as you have discovered that the weather plugin can block the UI, which I have also discovered myself. b. -- My other computer is your Microsoft Windows server. Brian J. Murrell
signature.asc
Description: This is a digitally signed message part
