On Thursday, December 11, 2014 4:53:04 AM UTC, 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
It looks to me that what you are doing is sharing a single core between your GUI and your processing. Threading isn't usually a good approach to Python concurrency that is CPU-bound. Simply changing ThreadPoolExecutor to ProcessPoolExecutor will improve performance, but will still allow the UI to freeze. The approach I use for concurrency in GUI applications is for the GUI to run in the main thread (the default, and there's no choice) and to create a "manager" thread that does almost no work. This means that the GUI thread gets almost all the processing on the core on which it runs. Whenever there is work to do it is passed to the manager thread which immediately gives it to someone else. The someone else is a process pool. This ensures that the GUI doesn't freeze even in the face of lots of processing (because the processing is done in one or more separate processes). In my book "Python in Practice", http://www.qtrac.eu/pipbook.html there's an example of how to do this in chapter 4. The example uses Tkinter but I use exactly the same approach in PyQt and PySide. This chapter also discusses many issues related to Python concurrency. -- https://mail.python.org/mailman/listinfo/python-list
