在 2014年12月11日星期四UTC+8下午1时25分41秒，Michael Torrie写道： > 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.
"when it comes to I/O and GUIs, asynchronous calls are always better than threads." I cannot grasp your meaning here, IMO, asynchronous calls are done by using threads. -- https://mail.python.org/mailman/listinfo/python-list
