On 12/10/2014 09:52 PM, iMath wrote: > I think the user interface shouldn't be freezed when using > concurrent.futures.ThreadPoolExecutor here,as it executes > asynchronously , but it doesn't meet my expectations,anyone can > explain why ? any other solutions here to not let user interface > freezed? > > code is here > http://stackoverflow.com/questions/27393533/user-interface-freezed-when-using-concurrent-futures-threadpoolexecutor
In most any GUI framework, regardless of your use of threads, your callbacks must return control to the main loop immediately (whether an on-click or an on-timer event), or the GUI *will* freeze. You are spawning threads to download the urls, then sitting there waiting for them to finish in the callback. Of course the GUI will freeze; your callback is blocking it. What you should be doing is spawning the threads to do the download, then have the threads (using a proper QThread mechanism or some other semaphore mechanism) raise a signal to indicate they are done, which you will then catch in the main loop as a normal callback. And really when it comes to I/O and GUIs, asynchronous calls are always better than threads. Not sure what Qt has in the way of asynchronous i/o calls, and I'm not familiar enough with the various async i/o frameworks in Python to speak to that, though I did use Python-Twisted once... very powerful once you get your head wrapped around it. Look through the list archives because in the last 3 or 4 weeks I and another Python user talked proper thread use with PyQt or PySide, with code examples. -- https://mail.python.org/mailman/listinfo/python-list
