Dotaz: [Python] Jak na mezivlaknove callbacky?

[David Sedláček]

Ahojte, ve sve aplikaci celkem dost pouzivam callbacky.

Ale zacinam narazet na problemy s mezivlaknovym volanim. PyQt obcas spadne, kdyz se napr widget manipuluje z callbacku v jinem threadu, nez ve kterem byl vytvoren.

Jak resit problemy s mezivlaknovymi callbacky? Resp jak osetrit, aby se callback volal ze stejneho threadu, ve kterem byla vytvorena instance tridy?

Nejaky vzor ci neco podobneho - urcite nejsem sam, kdo ma podobny problem.

Odpovědi

[petr b]

Ahoj, já sice dělám ve wxPythonu, ale tam je stejný problém. Teda on to ani tak není problém jako vlastnost. Platí, že to co dělám v UI musí být v jednom threadu, a když už mám threadů víc, tak posílám eventy. Případně eventy v kombinaci s frontou.

# Muj vlastni super event, ktery dela super veci
(SuperEvent, EVT_SUPER) = wx.lib.newevent.NewEvent()
# ...
wx.PostEvent(target_window, super_event_instance)

což je zamozřejmně wx-specific, ale v QT to bude dost podobné.

A k tomu případně import Queue

[David Sedláček]

Aplikaci bych chtel co nejvice v Pythonu. Asi chapu, kam miris, ale musel bych vyuzit qt threading. Podle toho co jsem pochopil z diskusi na netu.

Ta fronta je zajimavy napad. Stale premyslim, jak spousteni tasku managujicich gui zajistit pouze z jednoho hlavniho threadu. Problem vidim v tom, ze Qt ten thread spolkne cely a otazka je, jak do nej napasovat management te fronty tasku.

[pavlix]

Předpokládám, že má Qt stejně jako ostatní podobné frameworky nějaký main loop, do kterého se dají přidávat další události založené na souborových deskriptorech. Potom je v Pythonu potřeba využívat prostředků, které ty souborové deskriptory nabízejí. Za tím celým je stejně nějaké jednoduché zavolání select/poll/epoll syscallu.

[Ivan]

I v QTcku je to tak. S UI by melo pracova poze hlavni vlakno. Navic v QTco ka kazdy object tzv. tread afinity, tzn kazdy objekt si pamatuje kontext vlakna ve kterem byl vytvoren. Pokud zavolas connect na dva objekty z ruznych vlaken, tak QTcko samo pochopi, ze se zprava musi predavat mezi vlakny.

Asi pri precti tohle: http://blog.qt.digia.com/blog/2010/06/17/youre-doing-it-wrong/ http://woboq.com/blog/qthread-you-were-not-doing-so-wrong.html

[David Sedláček]

V QT, potazmo s Pythonem delam asi dva tydny. Muzes mi prosim naznacit nejake reseni?

QT jsem chtel pouzit pouze na GUI a zbytek psat pouze v Pythonu (threading). Vsak tohle muselo resit X lidi predemnou?

[Ivan]

Ja zase neznam Python :(. Kazdopadne aby to vybec mohlo fungovat asychronne tak:
- hlavni vlakno musi procesovat QT event loop
- pak potrebujes alespon jedno dalsi vlakno vytvorene pomoci QT knihovny, tohle vlakno muze posilat eventy do vlavniho UI threadu.
- ostatni vlakna (non-QT) budou vkladat udalosti do fronty(chranene mutexem), background QT thread je bude vyzvedavat a preposilat(emit) dal.
Asi by to slo i jednoduseji, ale tomu QT se nevyhnes. Protoze to co se posila pres emit musi byt potomek QObjektu a navic to musi byt registrovany QT-meta objekt a navic to musi byt "klonovatelne". Pokus zavolas emit v jednom vlakne, tak se do druheho vlakna doruci kopie.

[David Sedláček]

No nakonec jsem to v ramci rychlosti a relativni jednoduchosti vyresil vyuzitim QThread (viz muj prispevek na konci vlakna)

Muzu v klidu pracovat v Pythonu a pokud chci sahat do Qt GUI, pouziju tu tridu, ktera je potomkem QThread. A nemotam do Py jadra aplikace Qtcko.

[David Sedláček]

Na druhou stranu volat Qt thread z nahodilych threadu tez neni moc stastne. Ale chtel bych poznat nejake pure-Python reseni bez Qt threadingu.

[Jardik]

Fronta, zamykat mutexem zapis/cteni a nejak to integrovat do event loopu z Qt, takze Qt se tedy uplne nevyhnes. Qt totiz ma jakousi event loopu, kde ceka na nove eventy a pak podle toho neco vola. A Qt pak musi vedet, ze mas nejakou frontu, kde kdyz neco je, ze ma Qt neco zavolat. A nebo treba pouzit nejaky ten Qt timer, pokud nezalezi na rychlosti, ale pokud chces frontu kontrolovat v nejakym intervalu a nezalezi moc na presnosti.

[David Sedláček]

Tak jsem to nakonec vyresil takovou "proxynou"

class PyQtProxyThread(QThread):
    __signalName = 's'
    def __init__(self, _destinationCallable, _data):
        assert callable(_destinationCallable)
        QThread.__init__(self)
        self.__data = _data
        self.connect(self, SIGNAL(self.__signalName), _destinationCallable)
        self.start()

    def __del__(self):
        self.wait()

    def run(self):
        self.emit(SIGNAL(self.__signalName), self.__data)

[skunkOS]

// Volano z gui vlakna, treba z hlavniho okna aplikace.
QThread *thread = new QThread;
Worker *pracovnik = new Worker(); // pracovnik dedi QObject
pracovnik->moveToThread(thread);

// A ted pokud potrebujes predávat data z pracovnika (ktery bezi na jinem vlakne) do hlavniho vlakna, tak to delej pres signaly.
connect(pracovnik, SIGNAL(abc()), this, SLOT(abc()));

Jak bylo řečeno, connect() automaticky pozna, že slot se nachazi v jinem vlakně nez signal a provede automaticky mezivlaknovej invoke.

[Ivan]

Jinak jeste jeden tip, pokud pouzivas Linux. Pokud bys' opravdu chtel sahat na GUI z ostatnich vlaken tak bys' mel jeste zavolat neco jako QCoreApplication::setAttribute(Qt::AA_X11InitThreads); hned pri startu aplikace. Pokud to neudelas, tak muzes sestrelit Unity (anebo jiny WM) popr. muze umrit tvoje aplikace. Xlib byla katastrofa (co se multithreadingu tyce) a XCB na tom neni o moc lip.

[Jardík]

Pokud to neudelas, tak muzes sestrelit Unity (anebo jiny WM) popr. muze umrit tvoje aplikace

Ano, tvoje aplikace umřít může, ale to, že sestřelíš Unity či jiný WM je samozřejmě krávovina, leda by byl zabugovaný. Kecáš totiž přes socket s Xkama, popř. něco přes sdílenou paměť (třeba obrázky) a X server potom s WM úplně jiným socketem. A to, jestli je tvoje aplikace vícevláknová pro WM neznamená vůbec žádný problém.

[Josef Kufner]

Aby jsi se nedivil. Těch chyb v X serveru a desktopových prostředích je kopec. Pokud tvoje aplikace začne komunikovat příliš zvrhle, může nějakou najít a poslat celý desktop k zemi. Obzvlášť OpenGL hry v kombinaci s příliš syrovými drivery by mohly vyprávět.

[Jardík]

Tak takové chyby je třeba řešit. Ale pochybuju, že nějak souvisí s tím, že je aplikace vícevláknová a používá nějaké xlib či xcb špatně, protože to stejně všechno leze přes socket. A na chybný X request (kvůli patlálo matlálo zapisování dat z více vláken najednou) by měl x server odpovědět patřičnou chybou či klienta odpojit, nikoliv spadnout.

[Jardík]

Jinak o miliónech race condition v samotném návrhu X protokolu už bylo napsáno taky mnoho. Pokud s tím aplikace nepočítají, jejich programátor to neví, atd, tak je to problém.

[Ivan]

Samozrejme ze je to kravovina, bohuzel je to i smutny fakt :(. WM "odposlouchava" komunikaci aplikace s Xkama a casto ma nejake predpoklady. Pokud se ty predpoklady nesplni, tak se zacnou dit divny veci. Napriklad Unity lze (anebo spis slo) sestrelit tim, ze aplikace pridavala a odebirala polozky se sveho menu (namisto toho aby je jen prejmenovavala anebo shovavala). Takze kdyz se z menu odebirala a zase pridavala polozka "Tools" tak mela pokazde jine id. Bohuzel Unity, kdyz posloucha Xeventy, tak se chyta na oboji, jak jak na jmeno polozky v menu, tak a i na to ID.

Dalsi problem muze nastat kdyz menis kurzor z normalniho na presipaci hodiny (a nazpatek), bez tyhle volby se muze stat, tak uz ten normalni kurzor(sipka) nejde vratit.

[Ivan]

Kdyz tak o tom premyslim, tak ten priklad s menu je blbost. Unity ma navic svuj vlastni plugin primo v QT knihovne, v tom priklade s menu se sral ten qt plugin. Jinak jen priklad co jsem uvadel nakonec zavola funkci "XInitThreads" z xlib/xcb, ktera rekne te knihovne, ze bude pouzivana v multi-threaded modu(neni to default) - bez toho nedojne k inicializaci nejakych zamku.

[David Sedláček]

Aplikace na 99 % pojede jen na Xkach, WM manager nastesti nepotrebuju, ale dobre vedet, ze se neco takoveho muze stat. By me nenapadlo ze muzu svou app sestrelit WM? !!?!!