PyQt: user interface freezed when using concurrent.futures.ThreadPoolExecutor

[iMath]

在 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.