Thread abschießen, wann?

[BlueJay]

Hallo Leute,

Basis: Java 1.4, Java2ME

da ist eine Main-Klasse (Midlet),
diese generiert ein Canvas-Objekt,
dieses Canvas-Objekt startet 2 (private) Threads.

Die Main-Klasse wird, wodurch auch immer, abgeschossen.
Sie schafft es noch, das Canvas-Objekt abzuschießen, hat aber von dem Threads in diesem Objekt keine Ahnung.

Frage: was passiert mit dem Threads? Loopen die noch weiter im Hintergrund?

Zusatz: das Canvas-Objekt bedient sich (versucht es jedenfalls) an der veralteten Methode stop, um den Thread abzuschießen.

so long,
BlueJay

[anda_skoa]

Threads abschießen kann man praktisch vergessen.

Am besten man teilt dem Thread bzw. dem ausgeführten Runnable mit, dass es abbrechen soll.

Wenn man ganz sicher gehen will, dass der Threads das "gesehen" hat, muss man entsprechend mit wait() und notify() arbeiten.

Ciao,
_

[BlueJay]

Am besten man teilt dem Thread bzw. dem ausgeführten Runnable mit, dass es abbrechen soll.

Reicht es da, den Thread-Pointer auf Null zu setzen? Zumindest die Schleifenbedingung sagt, nur solange laufen, wie der Pointer !=null ist.
Stop ist ja deprecated, und die J2ME-Bibiliothek des WTK 2.2 bietet keinen Ersatz an.

Aber ich sehe es richtig, dass ein Thread-Objekt weiterläuft, auch wenn das erzeugende Objekt gehimmelt wurde?

Zusatz: Versuche mit dem WTK2.2-Emulator:
das destroy einiger Objekte scheint bei Abschuss nicht immer durchlaufen zu werden, die Threads leben weiter, z.B. dieser

  public dipolfeld() 
  { for (int i=0; i<numdipol; i++) { my_dipol[i]=new dipol(); a_dipol[i]=new dipol(); }
    whatnext=3;
    thread1=new Thread(this);
    thread1.start(); 
  }

  public void run()
  { while (Thread.currentThread() == thread1)
    { switch(whatnext)
      { case 1: sim_laeuft=false; geschafft=true; whatnext=2; break;
        case 2: whatnext=3; break;    // netten Endescreen einblenden
        case 3: break;                // Pause
        default: zeit++; messi="Time: "+tformat(zeit);
      }
      try { Thread.sleep(1000); } catch (InterruptedException e) { break; }
    }
  }
  public void stop() { thread1 = null; }

  void destroy() { thread1=null; }

Effekt: Nach Restart über Notausstieg wird die Anzeige zwar weiterhin im Sekundentakt refresht (messi), aber der Zeitcounter (zeit++) läuft doppelt schnell. Man sieht auch, wie sich die Thread-Switches "anhäufen" (Emulator, Taste Auflegen schießt die Anwendung irgendwie ab, sie muss neu gestartet werden).

[anda_skoa]

Reicht es da, den Thread-Pointer auf Null zu setzen?

In deinem Fall ja, wegen deiner Abbruchbedingung. Allerdings wäre es IMHO schöner, als Abbruchbedingung einfach eine boolsche Variable zu benutzen.

Stop ist ja deprecated, und die J2ME-Bibiliothek des WTK 2.2 bietet keinen Ersatz an.

Das ist mindestens schon seit JDK1.1 deprecated, eher schon immer

Ciao,
_

[BlueJay]

Auch hier gibt es wieder eine Lösung, die heisst: Am Handy ausprobieren! Leider habe ich das Ding, wenn überhaupt, nur samstags.

Es sollte bei der "Absturz-Taste" eine Handy-Auswahl vom Betriebssystem kommen, die u.a. einen geordneten Rückzug anbietet, die Emu schafft das nicht und bricht zwischen Gut und Böse ab.

so long,
BlueJay

[anda_skoa]

Wenn ich das jetzt richtig verstehe, ist das Problem auf der eigentlichen Zielplattform nicht so schlimm oder gar nicht vorhanden.

Trotzdem:
Ist "Absturz" schon bevor du den Thread abschießen willst, oder mehr das "Clean-up" danach?

Ciao,
_

[BlueJay]

Hmmm, der Absturz passiert beim Betätigen des Hang-up-Buttons (roter Knopf). Habe mir inzwischen so viel angelesen, dass das Midlet auf einem richtigen Handy dann entweder in pauseApp oder destroyApp geht, je nach Hersteller und Jahrgang.
beim KRZR K1 kommt dieses Menu mit Abbruch/weitermachen/in den Hintergrund schieben.
Beim Emulator geht der Thread wohl in pause und das Midlet in destroy. , alles ohne Fehlermeldung. Nur beim nächsten Start ist der Zeitticker dann doppelt schnell - das ist alles, was man davon merkt.

Dummerweise hat sich gestern Männes Handy "aufgehangen", und ich bin natürlich die Schuldige.

  public void startApp() throws MIDletStateChangeException
  { canvas.my_game.neu(0,0);  // liest Standard-Daten ein
     canvas.start();                   // schaltet den Screen um
  }

  public void pauseApp() {  }
 
  public void destroyApp(boolean unc) throws MIDletStateChangeException
  { canvas.my_game.stop(); // lässt Berechnungs-Thread auslaufen
    canvas.stop();                // lässt Darstellungsthread auslaufen
    canvas.destroy();
    canvas2.destroy();
  }

...
    else if (cmd==exit)
    {  try
       { destroyApp(false);
          notifyDestroyed();
       }
       catch (MIDletStateChangeException ex) { }
     }
...

destroyApp wird vom cmdExit angesprungen, und dann funktioniert es auch zuverlässig.
in canvas.start() und canvas.my_game() werden keine Threads gestartet, von daher sollte auch alles sauber sein.

Ist der Canvas im Hintergrund, werden die Threads mit einem Flag auf "Durchzug" gesetzt (notify).

Die beiden stop() lassen die Threads auslaufen.

Siehst du oder sonst irgendjemand irgendeine Stelle, wo das Programm sich im Speicher "festhaken" kann?

so long,
BlueJay

[BlueJay]

Hm, schade dass dieser Link nicht (mehr) funktioniert:

Bug ID: 6394579 End button not functioning
bugs.sun.com/bugdatabase/view_bug.do?bug_id=6394579 - 20k -

[BlueJay]

Ging wieder.
Tja, da muss ich wohl das wtk updaten