On Thu, Oct 23, 2003 at 12:00:54PM -0400, Brian J. Murrell wrote: > This is the wrong way to fix this kind of problem in general and likely > specifically with Freevo.
I agree with you there. But the main reason I did it this way was because we're in a code freeze and I don't want to make an architectural change right now, even though I'm fairly sure that the socket stuff in Python in thread safe. > 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. Agreed. > 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. You're correct, there is no real reason why the display should have to wait for the data, it could easily be asynchronous since the weather is updated only ever 3600 seconds, it could even happen sometime during that hour. But the best case would be to do the fetch every 3600 hours in the "background" and update the display when data is actually available. > 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. As Freevo gains more threaded features, we'll probably have to do that. > 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. Sounds like something that definitely should go into 1.5... Offhand I know that CDDB lookups, IMDB lookups, weather, could concievably block the UI; the most concerning is obviously anything that goes into the idlebar since it should be completely "offscreen" ------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
