Threading w aplikacji PyQt: używać wątków Qt czy wątków Pythona?

Wątki Pythona będą prostsze i bezpieczniejsze, a ponieważ są przeznaczone dla aplikacji opartych na I / O, są w stanie ominąć GIL. Czy rozważałeś nieblokujące wejścia / wyjścia za pomocą skręconych lub nieblokujących gniazd / select?

EDIT: więcej o wątkach

WÄ…tki Pythona

Wątki Pythona są wątkami systemowymi. Jednak Python używa globalnej blokady interpretera (Gil), aby zapewnić, że interpreter wykonuje tylko określony rozmiar bloku bajtowego kodu instrukcje na raz. Na szczęście Python uwalnia GIL podczas operacji wejścia/wyjścia, czyniąc wątki użytecznymi do symulacji nieblokujących we/wy.

Ważne zastrzeżenie: Może to być mylące, ponieważ liczba instrukcji w kodzie bajtowym nie odpowiada liczbie linii w programie. Nawet pojedyncze przypisanie może nie być atomowe w Pythonie, więc blokada mutex jest konieczna dla dowolnego bloku kodu, który musi być wykonany atomicznie, nawet z GIL.

WÄ…tki QT

Gdy Python przekazuje kontrolę 3rd party skompilowany moduł, zwalnia GIL. Zadaniem modułu jest zapewnienie atomiczności tam, gdzie jest to wymagane. Gdy kontrola zostanie przekazana z powrotem, Python użyje GIL. Może to sprawić, że korzystanie z bibliotek innych firm w połączeniu z wątkami będzie mylące. Jeszcze trudniej jest użyć zewnętrznej biblioteki wątków, ponieważ dodaje niepewność co do tego, gdzie i kiedy kontrola jest w rękach modułu vs Tłumacz.

Wątki QT działają z wypuszczonym GIL. Wątki QT są w stanie wykonywać jednocześnie kod biblioteki QT (i inny skompilowany kod modułu, który nie nabywa GIL). Jednak Kod Pythona wykonywany w kontekście wątku QT nadal przejmuje GIL, a teraz musisz zarządzać dwoma zestawami logiki do blokowania kodu.

W końcu, zarówno wątki QT, jak i wątki Pythona są owijaczami wokół wątków systemowych. Wątki Pythona to marginalnie bezpieczniejsze w użyciu, ponieważ te części, które nie są napisane w Pythonie (w domyśle używając GIL) używają GIL w każdym przypadku (chociaż powyższe zastrzeżenie nadal ma zastosowanie.)

NieblokujÄ…ce we / wy

Wątki zwiększają złożoność Twojej aplikacji. Szczególnie, gdy mamy do czynienia z już złożoną interakcją między interpreterem Pythona a skompilowanym kodem modułu. Podczas gdy wielu uważa programowanie oparte na zdarzeniach za trudne do naśladowania, oparte na zdarzeniach, nieblokujące We/Wy często są znacznie mniej trudne do rozumowania niż wątki.

Przy asynchronicznych we/wy zawsze możesz być pewien, że dla każdego otwartego deskryptora ścieżka wykonania jest spójna i uporządkowana. Istnieją oczywiście problemy, które należy rozwiązać, takie jak co zrobić, gdy kod zależny od jednego otwartego kanału dalej zależy od wyników kodu, który ma być wywołany, gdy inny otwarty kanał zwraca dane.

Dobrym rozwiązaniem dla nieblokujących I/O opartych na zdarzeniach jest nowa biblioteka Diesel . Informatyka jest ograniczony do Linuksa w tej chwili, ale jest niezwykle szybki i dość elegancki.

Warto również poświęcić swój czas na nauczenie się pyevent , owijki wokół wspaniałej biblioteki libevent, która zapewnia podstawowy framework do programowania opartego na zdarzeniach przy użyciu najszybszej dostępnej metody dla Twojego systemu (określonej w czasie kompilacji).

ZaletÄ… QThread jest to, że jest zintegrowany z resztÄ… biblioteki Qt. Oznacza to, że metody obsÅ‚ugujÄ…ce wÄ…tki w Qt bÄ™dÄ… musiaÅ‚y wiedzieć, w którym wÄ…tku dziaÅ‚ajÄ…, a aby przenosić obiekty miÄ™dzy wÄ…tkami, należy użyć QThread. InnÄ… przydatnÄ… funkcjÄ… jest uruchamianie wÅ‚asnej pÄ™tli zdarzeÅ„ w wÄ…tku.

JeÅ›li uzyskujesz dostÄ™p do serwera HTTP, powinieneÅ› rozważyć QNetworkAccessManager.

Zadałem sobie to samo pytanie, kiedy pracowałem nad PyTalk .

JeÅ›li używasz Qt, musisz użyć QThread, aby móc korzystać z Qt framework i przede wszystkim system sygnaÅ‚owo-szczelinowy.

Dzięki silnikowi sygnału / gniazda będziesz mógł rozmawiać z jednego wątku do drugiego i z każdą częścią twojego projektu.

Co więcej, nie ma zbyt dużego pytania o wydajność tego wyboru, ponieważ oba są wiązaniami C++.

Oto moje doświadczenia z PyQt i nić.

ZachÄ™cam do korzystania QThread.

Jeff ma kilka dobrych punktów. Tylko jeden główny wÄ…tek może dokonać aktualizacji GUI. JeÅ›li musisz zaktualizować GUI z poziomu wÄ…tku, sygnaÅ‚y Qt-4 queued connection uÅ‚atwiajÄ… wysyÅ‚anie danych miÄ™dzy wÄ…tkami i bÄ™dÄ… automatycznie wywoÅ‚ywane, jeÅ›li używasz QThread; nie jestem pewien, czy bÄ™dÄ…, jeÅ›li używasz wÄ…tków Pythona, chociaż Å‚atwo jest dodać parametr do connect().

Ja też nie polecam, ale mogę spróbować opisać różnice między wątkami CPython i Qt.

Po pierwsze, wątki CPython nie działają jednocześnie, przynajmniej nie w Pythonie. Tak, tworzą one wątki systemowe dla każdego wątku Pythona, jednak tylko wątek aktualnie posiadający globalną blokadę interpretera może być uruchomiony(rozszerzenia C i Kod FFI mogą go ominąć, ale bajtowy kod Pythona nie jest wykonywany, podczas gdy wątek nie posiada GIL).

Z drugiej strony mamy Qt wątki, które są zasadniczo wspólną warstwą nad wątkami systemowymi, nie mają globalnej blokady interpretera, a zatem mogą działać jednocześnie. Nie jestem pewien, jak radzi sobie z tym PyQt, jednak jeśli twoje wątki Qt nie wywołują kodu Pythona, powinny być w stanie działać jednocześnie (Pasek różnych dodatkowych blokad, które mogą być zaimplementowane w różnych strukturach).

Aby uzyskać dodatkowe dostrojenie, możesz zmodyfikować ilość instrukcji kodu bajtowego, które są interpretowane przed zmianą własności GIL-lower wartości oznaczają więcej przełączania kontekstowego (i prawdopodobnie wyższą responsywność), ale niższą wydajność na pojedynczy wątek (przełączniki kontekstowe mają swój koszt - jeśli próbujesz przełączać co kilka instrukcji, nie pomaga to w szybkości.)

Mam nadzieję, że pomoże w twoich problemach:)

Nie mogÄ™ skomentować dokÅ‚adnych różnic miÄ™dzy wÄ…tkami Pythona i PyQt, ale robiÅ‚em to, co próbujesz zrobić za pomocÄ… QThread, QNetworkAcessManager i upewnij siÄ™, że zadzwonisz QApplication.processEvents(), gdy wÄ…tek jest żywy. JeÅ›li problem, który próbujesz rozwiÄ…zać, to responsywność GUI, pomoże późniejsze.