Moin, On Monday 15 January 2007 08:46, Timo Doerr wrote: [...] > ich muss mehrere AB_BANKING handles gleichzeitig geöffnet halten um > gleichzeit auf verschiedene Konten zugreifen zu können. Soweit ich das > rausbekommen habe is das kein Problem, solange ich mehrere meiner > anwendungen ausführe, jede mit anderem appName und eigenem > config-verzeichnis und jede in ihrem eigenen speicherkontext (und daher > jede mit einer eigenen instanz vonder libaqbanking.so und libgwen.so). Da > ich aber threading verwenden will, habe ich das problem das > AB_Banking_Init() fehlschlägt, als ausgabe erhalte ich dann: [...] Ich verstehe nicht ganz, warum Du mehrere AB_Banking's brauchst? Im uebrigen kann ich auch schlecht sagen, wie die verschiedenen Plugins reagieren, wenn sie in verschiedene AB_Banking' geladen werden. Zwar verwenden die Plugins selber erst mal keine globalen Variablen (sondern nur welche in ihrem jeweiligen AB_PROVIDER Kontext) aber ich habe das noch nie mit Multithreading getestet. AqBanking selbst ist auch nicht thread-safe.
Bei der parallelen Abarbeitung mehrerer Job-Queues bekommst Du unter Umstaenden auch Probleme, sobald beide Threads zum Beispiel nach einer Pin fragen oder Fortschrittsfenster oeffnen: Da wird es eventuell fuer den Anwender etwas schwierig zu sehen, wo er was eingeben oder lesen muss (ausserdem weiss ich nicht, wie QT das handhabt, wenn mehrere MessageBoxes gleichzeitig offen sind). Insbesondere sind auch die Netzwerk-Funktionen in Gwen nicht thread-safe. Wenn also mehrere Threads zur gleichen Zeit GWEN_Net_Heartbeat aufrufen, koennte das zu Problemen fuehren. Fazit: AqBanking ist bisher nicht fuer Multithreading ausgelegt. Ich hatte mich damals bewusst dagegen entschieden, in AqHBCI mehrere Verbindungen gleichzeitig zu oeffnen (obwohl das gar nicht so schwierig zu realisieren ist, auch ohne Mutlithreading, weil ja der Netzwerk-Code asynchron ist). Zum einen sind die Banking-Server einfach schnell genug, als dass der Aufwand lohnen wuerde, zum anderen wird das Debugging dann exponentiell schwieriger. Und HBCI ist schon kompliziert genug, da wollte ich wenigstens die Lib so einfach und wartbar wie moeglich halten. [...] > base/pathmanager.c die variable gwen__paths global deklariert is. Beim [...] Das ist auch mit Absicht so, weil mehrere parallele Plugin-manager beispielsweise sinnlos sind. Und bei den Netzwerk-Funktionen bin ich sogar darauf angewiesen, dass die Liste der GWEN_NETLAYER global ist, weil ich nur so zum Beispiel sinnvol den select()-Aufruf verwenden kann (weil ich in GWEN ja weiss, welche Netlayer auf Aktivitiaet warten). So hat es sich bisher schlicht bewaehrt. Man koennte natuerlich darueber nachdenken, wie man vorgeht, damit mehrere Threads auf die Netzwerk-Funktionen zugreifen koennen: Wenn beispielsweise auf Aktivitaet gewartet werden soll, koennte ja der 2. Thread feststellen, dass schon ein Thread mittels select() auf Aktivitaet wartet, und dann einfach solange schlafen, bis der 1. Thread aufgewacht ist (weil entweder das Timeout abgelaufen ist oder Aktivitaet festgestellt wurde). Dann koennte der 2. Thread direkt seine entsprechenden Ergebnisse auslesen, ohne selber noch select() aufrufen zu muessen (was ja sinnlos waere, weil ja gerade der 1. Thread select() ausgefuehrt hatte). Es ist jedenfalls wichtig, dass nur jeweils ein Thread den Code aus GWEN_Net_Heartbeat() ausfuehrt. [...] > Da die pfade in /usr/lib/aqbanking/* für den user ja sowieso read-only > sind steht doch einer parallen öffnung imho nichts im wege. Da ich [...] Die parallele Oeffnung ist auch nicht das Problem, sondern die Speicherung der Pfade im PathManager: Beispielsweise definiert GWEN einen Pfad zu den Plugins fuer CryptToken. Gwen selber liefert auch schon CryptToken mit, auf die zum Beispiel AqBanking zugreift (->OpenHBCI-Schluesseldatei). Libchipcard bietet dann noch die CryptToken-Plugins fuer Chipkarten, und AqBanking liefert selber auch noch eines, naemlich fuer PinTan. Alle 3 Teile muessen nun den gleichen PluginManager (und damit intern den gleichen PathManager) verwenden, sonst werden von der Anwendung die Plugins nicht gefunden. Daher macht es hier durchaus Sinn, dass diese in Gwen global verwaltet werden. [...] > Die angekündigten änderungen am aqbanking hören sich ja sehr > vielversrechend an, wie schauts dort gegenwärtig aus mit multi-threading? > Wann ist mit einem ersten vorab release zu rechnen, bzw gibts ein CVS/SVN > der schon brauchbar ist zur kontostands/transaktionsabfrage? Lohnt sich > das überhaupt noch an 2.2.4 und gwen 2.5 rumzubasteln? [...] Auch der neue Code ist nicht thread-safe, weil ich mich fuer meine Projekte weitestgehend gegen Mutlithreading entschieden habe. Der asynchrone Netzwerk-Code in Gwen ist ueberhaupt nur deswegen entstanden, um mehrere Netzwerkverbindungen (von mehreren Bibliotheken gleichzeitig) auch ohne Multithreading parallel nutzen zu koennen. Ich weiss natuerlich auch, dass Multithreading eine elegante und im passenden Anwendungsfall sinnvolle Moeglichkeit darstellt, aber fuer mich sehe ich keine Notwendigkeit dafuer in AqBanking, deshalb ist es halt auch nicht thread-safe. Grundsaetzlich lohnt es sich aber nicht, noch an Gwen/AqBanking 2 zu experimentieren, weil ich es nach Abschluss von Version 3 nicht weiterentwickeln werde (Bugfixes natuerlich ja, aber keine neuen Entwicklungen). Gruss Martin -- "Things are only impossible until they're not" AqBanking - http://www.aqbanking.de/ LibChipcard - http://www.libchipcard.de/ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Aqbanking-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/aqbanking-devel
