> 
> On Dec 5, 2019, at 7:18 AM, Jason H <jh...@gmx.com> wrote:
> 
>  
> I don't thinkso. The Python multiprocessing module uses multiple processes, 
> so you have to copy data between them. QThreads are in the same process so no 
> copy is needed.
> GIL only matters when you're in interpreted code.

Yes, but we’re talking about threads vs QThread - I already ruled out the 
python multiprocessing module due to the data copy issue. You are correct that 
the GIL only matters when you’re in interpreted code, but given the behavior 
I’m seeing, I have to assume my function *is* interpreted code - that is, the 
time intensive portions are not calling C libraries. Otherwise running the 
function in a separate thread would work to keep the GUI responsive.

I did try using a QThread - with the same result as using a python thread. The 
GUI freezes while the function is running. As I stated before, I can only 
assume this is due to the GIL. And in case there is any question about if I 
used QThreads correctly or not, here is the code I used to start the thread:

thread = ResultsThread(self)
thread.resultsReady.connect(self._on_results_ready)
thread.start()

ResultsThread is, of course, a QThread subclass in which I re-implemented the 
run() function to do my calculations.

As a further test, I started another thread that just spit out the “current” 
time (as per time.time()) every .2 seconds. What I’m seeing is that under 
normal operation, this other thread outputs as expected every (approximately) 
.2 seconds. However, while the QThread (or python thread) is running, this 
other thread “stutters”. This indicates that while the QThread operation 
doesn’t block other threads completely, there are a number of operations taking 
place in it that *DO* block other threads for a noticeable length of time, 
causing the next iteration of my timer loop to be delayed. Such blocking would 
obviously apply to the main GUI thread as well.

So yes, running in a QThread blocks the main GUI thread the same as running in 
a python thread does.
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory 
Geophysical Institute - UAF 
2156 Koyukuk Drive 
Fairbanks AK 99775-7320
Work: 907-474-5172
cell:  907-328-9145

>  
>  
> Sent: Thursday, December 05, 2019 at 9:42 AM
> From: "Israel Brewster" <ijbrews...@alaska.edu>
> To: "Kerby Geffrard" <kerby.geffr...@autodesk.com>
> Cc: "pyside@qt-project.org" <pyside@qt-project.org>
> Subject: Re: [PySide] Keeping GUI responsive
> 
> On Dec 4, 2019, at 4:53 PM, Kerby Geffrard <kerby.geffr...@autodesk.com 
> <mailto:kerby.geffr...@autodesk.com>> wrote:
>  
> I think you can try to use a QThread for this.
>  
> I was under the impression that QThreads had the same limitations that 
> regular python threads had, but I’ll give it a shot. The need to subclass 
> QThread rather than simply being able to execute a function complicates 
> things however - I have to make sure that said subclass has access to all the 
> original class members it needs.
> ---
> Israel Brewster
> Software Engineer
> Alaska Volcano Observatory 
> Geophysical Institute - UAF 
> 2156 Koyukuk Drive 
> Fairbanks AK 99775-7320
> Work: 907-474-5172
> cell:  907-328-9145
>  
>  
> Le 4 déc. 2019 à 18:41, Israel Brewster <ijbrews...@alaska.edu 
> <mailto:ijbrews...@alaska.edu>> a écrit :
>  
>  I know this is a FAQ, however I haven’t been able to make any of the 
> standard answers work for me. Here’s the situation:
>  
> - using PySide2 5.12.2
> - I have an object (QMainWindow subclass) that contains most of the code for 
> my application
> - One of the functions that runs in response to user input takes around 2 
> seconds to run. The GUI obviously freezes during this time (BAD!)
> - Said function needs to access and modify several large variables (pandas 
> data frames) from the main object
>  
> So here’s the problem: If I run this function as a separate (python) thread, 
> that doesn’t help - the GUI is still frozen. I’m thinking this is due to the 
> GIL, but I could be wrong about that. Running under the multiprocessing 
> module, however, doesn’t appear to be an option due to the number and size of 
> the data structures that the function needs to modify, and if I try just to 
> see what happens, the process actually crashes.
>  
> So what are my options here? How can I keep the GUI responsive while this 
> function runs, without being able to spin it off as a separate process? Or is 
> the only option going to be to completely rip apart the function and try to 
> re-build it in such a way that it can, somehow, still access the memory from 
> the main thread, while doing the processing in a separate function?
> ---
> Israel Brewster
> Software Engineer
> Alaska Volcano Observatory 
> Geophysical Institute - UAF 
> 2156 Koyukuk Drive 
> Fairbanks AK 99775-7320
> Work: 907-474-5172
> cell:  907-328-9145
> _______________________________________________
> PySide mailing list
> PySide@qt-project.org <mailto:PySide@qt-project.org>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.qt-2Dproject.org_listinfo_pyside&d=DwIGaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=Sh-EhW_r32FEgrsAfK3Hc0du2ebOZ7PrbchABO_xtMo&m=r4Ron7tNrQN9BNhzXVlsKvYoyWrnjjOzLwALVV_CgnA&s=T2UjSQWTnYFAfFbfdTlMgLZnfC1dlXhNy1SmPijkWbs&e=
>  
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.qt-2Dproject.org_listinfo_pyside&d=DwIGaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=Sh-EhW_r32FEgrsAfK3Hc0du2ebOZ7PrbchABO_xtMo&m=r4Ron7tNrQN9BNhzXVlsKvYoyWrnjjOzLwALVV_CgnA&s=T2UjSQWTnYFAfFbfdTlMgLZnfC1dlXhNy1SmPijkWbs&e=>
> _______________________________________________ PySide mailing list 
> PySide@qt-project.org https://lists.qt-project.org/listinfo/pyside 
> <https://lists.qt-project.org/listinfo/pyside>
_______________________________________________
PySide mailing list
PySide@qt-project.org
https://lists.qt-project.org/listinfo/pyside

Reply via email to