> On Dec 6, 2019, at 9:28 AM, Bob Hood <bho...@comcast.net> wrote: > > On 12/6/2019 8:33 AM, Jason H wrote: >> I can confirm your experience on Mojave. >> >> If you increase your dataset 100-fold, then I get a beach ball. Based on >> what I am seeing here, QThread doesn't actually quite work. > > Perhaps I'm misunderstanding what you're trying to achieve, but…
To clarify the original objective: Given that: A) python threads can not execute simultaneously due to the GIL (unless one thread releases the GIL, which does not appear to be the case in my code, or perhaps due to something with PySide), AND B) my code does not lend itself to using multiprocessing rather than threading due to the large data structures involved (thus the reason the calculations take a while) - How can I keep the GUI responsive while the calculations proceed? So far the only solution I have come up with is to periodically call QApplication.processEvents() on the main thread from within my calculation code, but that is ugly and, according to everything I see online, indicative of a bad design. As I don’t want a bad design, what is the alternative? Or is this simply one of the rare cases where that *is* the correct answer? --- 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 > > Python is not multi-threaded: Never has been, and from what I can tell, > never will be. Qt isn't going to be able to magically change that. A > QThread is going to be blocked by the GIL if your execution path strays back > into any interpreted code.
_______________________________________________ PySide mailing list PySide@qt-project.org https://lists.qt-project.org/listinfo/pyside
