Fwd: Python Signal/Slot + QThred code analysis
Michael Torrie
torriem at gmail.com
Thu Nov 27 19:52:45 EST 2014
On 11/27/2014 04:29 PM, Juan Christian wrote:
> So, instantly I found one issue, you said that this code won't block the
> GUI, only the thread event loop, but if we keep moving the window while
> it's open, every time new info is printed the GUI freezes for like 1-2
> seconds.
Correct. The thread does not block the GUI. I cannot replicate your
problem on my machine here. Maybe we're finding a problem with Windows
and Qt. I can drag the window around and it keeps on a going.
> And why this approach of a single instance is better? I mean, I'll have to
> call Outpost every time I get new data from my other API, because there
> will be different users, so I need to create different instances so I call
> the site with a new ID, don't I?
Just seems wasteful, that's all. Why not instantiate Outpost from the
worker thread? Especially if your thread only does one thing every 5
seconds. Starting up a new thread and destroying seems like a waste.
But it certainly can be done that way.
> Maybe the answer for that question is that you using a timer that is ALWAYS
> active and ALWAYS calling the the outpost site, so I'll have something like:
>
> var = Outpost('12345')
> var.posts -> 100
> var.setID('67893')
> var.posts -> 35
>
> Is that right? But I don't think that always calling the site this way is
> good for them and for me, sometimes I may not get new users for like 10~15
> minutes, so I would have wasted a lot of calls for nothing. That's why I
> only instantiate/call the site when I get new users.
I was simply using the logic you originally provided. I have no idea
what Outpost does or how you use it. Your original code just grabbed
some data every 5 seconds, so that's what I got it to do in the most
efficient way. You'll have to adapt it to your real needs.
More information about the Python-list
mailing list