SDA SE Wiki

Software Engineering for Smart Data Analytics & Smart Data Analytics for Software Engineering

User Tools

Site Tools


Differences

This shows you the differences between two versions of the page.

Link to this comparison view

research:jtransformer:threadinguisyncresponsibility [2018/05/09 01:59] (current)
Line 1: Line 1:
 +
 +==== Ich habe kein Problem, **DU** hast ein Problem! ====
 +
 +
 +----
 +
 +Um Beiträge zu diesem Thema wird gebeten.
 +
 +----
 +
 +Darauf, daß aufrufe an die UI nur vom UI EPT ausgehen dürfen, wurde bereits hinreichend herumgeritten.
 +Die Frage ist: Wessen Problem ist das?​\\ ​
 +Mir erscheint es einleuchtend,​ daß hier zunächst der, der das Problem hat, dafür zuständig sein sollte, es zu lösen.
 +Hier sind meine Überlegungen dazu:
 +=== Listener //"​verantwortungsvoll"//​ implementieren ===
 +
 +Ist von Anfang an klar, daß eine Event Quelle Events ausschließlich an ein und den selben Empfänger absetzt, kann sie problemlos auf besondere Bedürfnisse des selben eingehen. Wird andererseits ein generisches Event/​Listener (bzw Subject/​Obsever) Pattern eingesetzt, sehe ich die Verantwortung eher auf seite des Empfängers. Ich kenne die SWT-API nicht gut genug um sagen zu können, welche Listener interfaces von Klassen implementiert werden, die davon abhängig sind, ausschließlich vom UI EPT aufgerufen zu werden. Bei Swing gibt es diese (leider): JTable hört natürlich auf sein [[tablemodel|tablemodel]]\\ ​
 +Ich habe es bei meinen eigenen Klassen bisher immer so gehalten, daß wenn ich mich als Listener um die Synchronisierung der Events (sofern nötig) gekümmert habe. Schließlich muß derjenige, der das tut ja auch wissen //wohin// (auf welchen Thread) mit den Events. Bei Swing ist das einfach da javax.swing.[[swingutillities|swingutillities]].invokeXXXX() statische Methoden sind. Das löst aber nicht das gundsätzliche Problem. Wie sieht'​s z.B. bei SWT aus?
 +
 +
 +
 +
 +
 +----
 +**apropos**//​Weils so gut passt, füge ich hier eine Mail ein, die ich an die Liste geschrieben habe://
 +
 +
 +
 +
 +
 +Hi Liste,
 +
 +
 +
 +Vielleicht fällt jemandem hierzu etwas ein:
 +bezgl ui aufrufe (die ja nur auf dem ui thread gemacht werden dürfen) ist mir folgende Merkwürdigkeit aufgefallen:​
 +In der eclipse docu heißt es
 +
 +<​Code>​
 +// now update the UI. We don't depend on the result,
 +// so use async.
 +Display.getCurrent().asyncExec(new Runnable() {
 +  public void run() {
 +    myWindow.redraw();​
 +  }
 +});</​Code>​
 +
 +Ha. Denkste.
 +Wer sich wie ich wundert warum das nicht funktioniert,​ sollte mal einen Blick auf die javadoc reference zu Display.getCurrent werfen, wo darauf hingewiesen wird, daß null zurückgegeben wird, sofern der aufrufende Thread _nicht_ der UI thread ist.
 +
 +
 +
 +Wozu also auch immer diese Methode da ist, zu obigem Zweck taugt sie nicht. :-(
 +Hab ich was übersehen? Andernfalls werde ich mal die Leute auf der eclipse liste fragen, ob daß nu so gewollt ist oder wie oder was.
 +
 +
 +
 +Ich habe mir übrigens in einem konkreten Fall anders behelfen können: Oft hat man ja (z.B. wenn man eine View implementiert) ein etwas intimeres Verhältnis zu den Widgets, die da schlussendlich benachrichtigt werden sollen. Von denen kriegt man ihre Display Instanz ebenfalls.
 +
 +
 +
 +Interessant in diesem Zusammenhang ist meiner Meinung nach auch die Frage danach, wer für die Synchronisierung mit dem Display Thread verantwortlich ist.
 +dazu: [[http://​roots.iai.uni-bonn.de/​lehre/​xp2004a1/​Wiki.jsp?​page=ThreadingUiSyncResponsibility|http://​roots.iai.uni-bonn.de/​lehre/​xp2004a1/​Wiki.jsp?​page=ThreadingUiSyncResponsibility]]
 +
 +
 +
 +knarz,​\\ ​
 +Lukas
 +
 +
 +
 +----
  
research/jtransformer/threadinguisyncresponsibility.txt · Last modified: 2018/05/09 01:59 (external edit)

SEWiki, © 2019