[java] Meerdere threads, thread killt programma

[Red devil]

Geachte tweakers,

In mijn java app (App A) staat een verwijzing naar een andere applicatie (App B ). App B wordt als nieuwe thread opgestart vanuit App A. Echter, als ik B afsluit, knalt A ook uit. Weet iemand hoe ik dit kan voorkomen, of afvangen?
Heb al gekeken of je een System.exit kunt afvangen, maar daar is haast niks over bekend.

[zwippie]

Een stukje van je code zou wel makkelijk zijn.
Start je App B met iets als

Java:

Process p = Runtime.getRuntime().exec("programma.exe");
p.waitFor();

of doe je dit anders?

System.exit() beeindigt de huidige Java VM. Als App A in dezelfde VM draait zal die app dus ook stoppen.

[Red devil]

zwippie schreef op vrijdag 01 december 2006 @ 15:35:
Een stukje van je code zou wel makkelijk zijn.
Start je App B met iets als

Java:

Process p = Runtime.getRuntime().exec("programma.exe");
p.waitFor();

of doe je dit anders?

System.exit() beeindigt de huidige Java VM. Als App A in dezelfde VM draait zal die app dus ook stoppen.

Sorry, ik zal even vollediger zijn:

Java:

Runnable runnable = new ApplicationObject();
//           Create the thread supplying it with the runnable object
Thread thread = new Thread(runnable);
thread.start();

Is er een manier om een programm netjes te laten stoppen? Zonder een system.exit te genereren? (ik druk nu op het kruisje om het programma te stoppen )

[D-Raven]

Ik ben niet zo bekend met Java hoor dus misschien zwets ik nu uit mijn nek.
Maar kun je niet in de eventhandler van je application close event (oid). CurrentThread.stop doen ofzow? Dus dat je de thread stopt en niet system.exit aanroept?

[makreel]

http://java.sun.com/docs/...applet/threadExample.html

bijv:
public void stop() {
animatorThread = null;
}

[ Voor 29% gewijzigd door makreel op 01-12-2006 16:09 ]

[Red devil]

makreel schreef op vrijdag 01 december 2006 @ 16:07:
http://java.sun.com/docs/...applet/threadExample.html

bijv:
public void stop() {
animatorThread = null;
}

Mmm ik heb niet echt een applet die om de zoveel ms iets synced ofzo. Dan werkt deze methode niet?

[makreel]

Wat gebeurt er als je

thread.stop()

doet?

[Marcj]

Een Thread heeft een run() functie die loopt zolang als de thread leeft. Als deze methode returned, dan is de Thread ook afgelopen. Dus in plaats van System.exit() in de run() functie doe je daar een return.

[Red devil]

makreel schreef op vrijdag 01 december 2006 @ 16:47:
Wat gebeurt er als je

thread.stop() doet?

Ik wil graag vanuit AppB de boel stoppen. Bedoel jij dat ik vanuit AppA tegen de thread van B stop moet zeggen?

Marcj schreef op vrijdag 01 december 2006 @ 16:47:
Een Thread heeft een run() functie die loopt zolang als de thread leeft. Als deze methode returned, dan is de Thread ook afgelopen. Dus in plaats van System.exit() in de run() functie doe je daar een return.

Mmm de run methode van mij mag niks returnen, ik zeg zelf ook niet dat ik System.exit() doe...

[makreel]

Hij hoeft ook niks te returnen, type dan:

return;

[Marcj]

Red devil schreef op vrijdag 01 december 2006 @ 17:03:
[...]


Ik wil graag vanuit AppB de boel stoppen. Bedoel jij dat ik vanuit AppA tegen de thread van B stop moet zeggen?


[...]


Mmm de run methode van mij mag niks returnen, ik zeg zelf ook niet dat ik System.exit() doe...

Ok, hoe eindigd die Thread dan? Wat roept dan de System.exit() aan? De run methode kan altijd returnen, ook als deze void is! Dan roep je gewoon

code:

return;

aan.

[zwippie]

@Makreel: thread.stop() aanroepen wordt sterk afgeraden.

Beter is dan om een variabele bij te houden die aangeeft of de thread klaar is met zijn werk.
Misschien heb je wat aan dit voorbeeld:

Java:

// Create and start the thread
    MyThread thread = new MyThread();
    thread.start();
    
    // Do work...
    
    // Stop the thread
    thread.allDone = true;
    
    class MyThread extends Thread {
        boolean allDone = false;
    
        // This method is called when the thread runs
        public void run() {
            while (true) {
                // Do work...
    
                if (allDone) {
                    return;
                }
    
                // Do work...
            }
        }
    }

[Red devil]

Marcj schreef op vrijdag 01 december 2006 @ 17:13:
[...]


Ok, hoe eindigd die Thread dan? Wat roept dan de System.exit() aan? De run methode kan altijd returnen, ook als deze void is! Dan roep je gewoon

code:

return;

aan.

Jo, idd return; kan ik in run methode plempen. Alleen werkt dat jammergenoeg niet.

[makreel]

Wat is de source van de runnable dan?

[Marcj]

Red devil schreef op vrijdag 01 december 2006 @ 17:20:
[...]


Jo, idd return; kan ik in run methode plempen. Alleen werkt dat jammergenoeg niet.

Als je returned uit een run methode van een Thread/Runnable dan eindigd die Thread altijd. Wat mogelijk is is dat vanuit die Thread andere worden gestart. Dit kan te maken hebben met bijvoorbeeld een GUI oid? Ik zal toch eerst echt wat meer moeten weten wat er gebeurd in die Thread voordat we kunnen concluderen waar de fout zit.

System.exit() kun je nooit afvangen. Deze methode beeindigd gewoon de VM (zoals al eerder gezegd).

[Red devil]

Marcj schreef op vrijdag 01 december 2006 @ 17:32:
[...]


Als je returned uit een run methode van een Thread/Runnable dan eindigd die Thread altijd. Wat mogelijk is is dat vanuit die Thread andere worden gestart. Dit kan te maken hebben met bijvoorbeeld een GUI oid? Ik zal toch eerst echt wat meer moeten weten wat er gebeurd in die Thread voordat we kunnen concluderen waar de fout zit.

System.exit() kun je nooit afvangen. Deze methode beeindigd gewoon de VM (zoals al eerder gezegd).

Mmmm ja, ik zie zelf op dit moment ook niet goed hoe ik bijv mbv een centrale check bij kan houden of de thread klaar is. Misschien 1 grote while maken, en die bij elke handeling checkt of een boolean is geset die zegt dat het programma moet stoppen.
App A is een programma om bepaalde data te minen, vervolgens wordt App B gestart om deze visueel te bestuderen. AppB is eigenlijk een soort grafische frontend met allerlei listeners e.d..
Deze worden in 1 dikke methode opgestart en vervolgens luistert het programma alleen maar naar de listeners enzo. Ik zal er even over nadenken, dacht eerst dat er wel een easy fix zou zijn maar dat is niet echt het geval .
Bedankt iig voor alle tips!

[Alarmnummer]

zwippie schreef op vrijdag 01 december 2006 @ 17:19:
@Makreel: thread.stop() aanroepen wordt sterk afgeraden.

Beter is dan om een variabele bij te houden die aangeeft of de thread klaar is met zijn werk.
Misschien heb je wat aan dit voorbeeld:

Java:

// Create and start the thread
    MyThread thread = new MyThread();
    thread.start();
    
    // Do work...
    
    // Stop the thread
    thread.allDone = true;
    
    class MyThread extends Thread {
        boolean allDone = false;
    
        // This method is called when the thread runs
        public void run() {
            while (true) {
                // Do work...
    
                if (allDone) {
                    return;
                }
    
                // Do work...
            }
        }
    }

Dit kon wel eens problemen opleveren

1) visibility probleem: een thread hoeft de waarde van allDone niet te zien als een andere thread er een wijziging in maakt.

2) de compiler kan zien dat de var access geen bijzondere is, dus hij kan er voor kiezen om de if(..)return weg te optimaliseren omdat er binnen de thread geen wijzing aan de allDone optreed.

Verder denk ik dat de topic starter er goed aan doet om uit te zoeken wat hij precies wil. Ik heb echt de indruk dat er een trial en error spelletje wordt gespeeld en dat is niet de manier om software te ontwikkelen.

[Red devil]

Alarmnummer schreef op vrijdag 01 december 2006 @ 21:11:
[...]

Dit kon wel eens problemen opleveren

1) visibility probleem: een thread hoeft de waarde van allDone niet te zien als een andere thread er een wijziging in maakt.

2) de compiler kan zien dat de var access geen bijzondere is, dus hij kan er voor kiezen om de if(..)return weg te optimaliseren omdat er binnen de thread geen wijzing aan de allDone optreed.

Verder denk ik dat de topic starter er goed aan doet om uit te zoeken wat hij precies wil. Ik heb echt de indruk dat er een trial en error spelletje wordt gespeeld en dat is niet de manier om software te ontwikkelen.

Volgens mij is dat wel duidelijk, App B netjes afsluiten zonder dat App A doodgaat. Middels de afsluitknop zal het mis gaan omdat de JVM ermee kapt.
Daarbij boeit het mij absoluut hoe netjes of hoe programmeer technisch correct de oplossing is, als het maar werkt.

[Alarmnummer]

Red devil schreef op zaterdag 02 december 2006 @ 12:42:
[...]


Volgens mij is dat wel duidelijk, App B netjes afsluiten zonder dat App A doodgaat. Middels de afsluitknop zal het mis gaan omdat de JVM ermee kapt.
Daarbij boeit het mij absoluut hoe netjes of hoe programmeer technisch correct de oplossing is, als het maar werkt.

Het werkt altijd als het correct is en als het niet correct is, werkt het als je geluk hebt regelmatig.

[Red devil]

Alarmnummer schreef op zaterdag 02 december 2006 @ 13:08:
[...]

Het werkt altijd als het correct is en als het niet correct is, werkt het als je geluk hebt regelmatig.

Ik heb kennelijk vaak geluk
Zelf zou ik ook alles wat beter en mooier opzetten en als dat snel haalbaar is, dan doe ik het natuurlijk zo. Maar heb nog maar weinig tijd en ik moet nog een hoop doen, daarom kies ik vaak voor de quick and dirty oplossingen.

[Marcj]

Red devil schreef op zaterdag 02 december 2006 @ 13:12:
[...]


Ik heb kennelijk vaak geluk
Zelf zou ik ook alles wat beter en mooier opzetten en als dat snel haalbaar is, dan doe ik het natuurlijk zo. Maar heb nog maar weinig tijd en ik moet nog een hoop doen, daarom kies ik vaak voor de quick and dirty oplossingen.

De quick & dirty oplossingen gaan je op de lange termijn alleen maar meer problemen opleveren en dus veel meer tijd kosten. Als je nu eerst goed nadenkt over hoe het ontwerp in elkaar zou moeten steken en dit op papier zet, dan gaat het implementeren en problemen oplossen ook vaak veel vlotter.

Maar goed, het is jou risico. Maar kom dan niet hier om te vragen hoe je een snelle fix voor een probleem kunt maken, terwijl het probleem veel dieper ligt.

Ooit gehoord dat de tijd die het kost om problemen op te lossen omgekeerd evenredig is met de fase waar het probleem ontstaan is? Als het probleem al ontstaan is bij het requirments opstellen, dan is het probleem oplossen vreselijk veel werk, terwijl implementatie problemen vaak vrij vlot op te lossen zijn (indien de vorige fases dus goed zijn!).

[onox]

Het lijkt mij netter om met otherThread.join(); te wachten tot dat die otherThread klaar is met het uitvoeren van zijn run() methode.

[Red devil]

Marcj schreef op zaterdag 02 december 2006 @ 13:18:
[...]


De quick & dirty oplossingen gaan je op de lange termijn alleen maar meer problemen opleveren en dus veel meer tijd kosten. Als je nu eerst goed nadenkt over hoe het ontwerp in elkaar zou moeten steken en dit op papier zet, dan gaat het implementeren en problemen oplossen ook vaak veel vlotter.

Ik heb nog 1 maand contract (loopt eind dit jaar af) en heb vervolgens misschien 5 maanden WW om nog 3 artikelen te schrijven, inleiding & discussie , nog een hele zooi implementatie werk + de analyse daarvan. Denk je dat ik ook maar iets geef om lange termijn problemen?

Maar goed, het is jou risico. Maar kom dan niet hier om te vragen hoe je een snelle fix voor een probleem kunt maken, terwijl het probleem veel dieper ligt.

Ooit gehoord dat de tijd die het kost om problemen op te lossen omgekeerd evenredig is met de fase waar het probleem ontstaan is? Als het probleem al ontstaan is bij het requirments opstellen, dan is het probleem oplossen vreselijk veel werk, terwijl implementatie problemen vaak vrij vlot op te lossen zijn (indien de vorige fases dus goed zijn!).

Voor hetzelfde geld, was er wel een snelle oplossing, die ik even 123 kon implementeren. Had ik geweten dat er geen snelle oplossing zou zijn, had ik dit dan hier aangekaart denk je? Daarbij is nauwelijks sprake van enige planning of requirements analyse voor de programma's in mijn project. Oh ja, die was er wel, daarmee hebben we 6 maanden tot 1 jaar verprutst, vanaf het moment dat ik zelf kon progselen ben ik uitermate pragmatisch te werk gegaan en niet zonder succes.
Wat denk je dat ik en mijn baas liever zien, 1 uitermate mooi programma met artikel zodat mensen het later eventueel (deze kans is vrij klein) zelf kunnen modificeren/aanpassen of 3 werkzame programma's (die onder de motorkap vrij rommelig lijken) met 3 artikelen.

[Alarmnummer]

Ga verder niet zelf met thread lopen kloten. Gebruik een executor (hou je veel beter controle over je threads, ook het aantal) en gebruik een future om te wachten op het klaar zijn van een taak. Furtures zijn in principe de meest eenvoudige oplossing, maar voor de mensen die wat avontuurlijker ingesteld zijn kun je ook kijken naar de CyclicBarrier (als alle slaves binnen zijn, kunnen ze allemaal verder) en CountDownLatch (als alle slaves zich hebben afgemeld, kunnen de masters verder).

[Red devil]

Alarmnummer schreef op zaterdag 02 december 2006 @ 13:51:
Ga verder niet zelf met thread lopen kloten. Gebruik een executor (hou je veel beter controle over je threads, ook het aantal) en gebruik een future om te wachten op het klaar zijn van een taak. Furtures zijn in principe de meest eenvoudige oplossing, maar voor de mensen die wat avontuurlijker ingesteld zijn kun je ook kijken naar de CyclicBarrier (als alle slaves binnen zijn, kunnen ze allemaal verder) en CountDownLatch (als alle slaves zich hebben afgemeld, kunnen de masters verder).

Thanks, heb hier nog een aardige posting gevonden.

[misfire]

Het probleem oplossen dat app B afsluiten betekent dat de JVM gestopt wordt:

Voorkom dat app B een System.exit() geeft bij het sluiten van de windows. Dit kan oa door op het JFrame de setDefaultCloseOperation() aan te roepen met een andere default actie, en te zoeken in code van app B naar system.exit() calls. Het is in de meeste gevallen niet netjes om system.exit() aan te roepen, dus moet het waarschijnlijk mogelijk zijn om de code te refactoren naar iets waar dit niet meer hoeft.

Het standaard mechanisme om lopende threads extern te stoppen is via de interrupt() methode. Door in de running thread loop te controleren op isInterrupted() of de InterruptedException af te vangen kan worden bepaald of de thread moet stoppen.

Hier een voorbeeld (met nette interrupt code en zonder system.exits):

Java:

public class Threading {
        
    public static void main(String[] args) throws InterruptedException {
        
        Thread thread = new Thread(new Runnable() {
            
            private int counter = 0;

            public void run() {
                while (!Thread.interrupted()) { // controleren op interrupt vlag.
                    System.out.println(counter++);
                    try {
                        Thread.sleep(500L);
                    } catch (InterruptedException e) {
                        break; // thread interrupted dus uit loop springen.
                    }           
                }
                System.out.println("Thread gestopt");
                Thread.currentThread().interrupt(); 
/* na controle interrupted/afvangen exception opnieuw interrupt vlag zetten! 
Thread.interrupted() zet namelijk de vlag altijd terug op false, 
en bij geneste methode calls zal de outer methode de interrupt anders niet meer zien. */
            } 
        });
        thread.start();
        Thread.sleep(2000L);
        thread.interrupt();
        thread.join(); // wachten totdat andere thread is gestopt
        System.out.println("Applicatie gestopt");        
    }
}

Vervolgens kun je dit hele verhaal nog combineren met Executors en Futures enz, maar als je de basis niet goed hebt (geen System.exit() aanroepen en netjes interrupten) dan zal het gewoon niet correct werken (al gaat het misschien regelmatig goed ).

Ik zou ook langer kijken dan de horizon van je contract. Je bent ook voor jezelf aan het werk, en als je nu kunt leren hoe je een probleem op een structurele manier kunt oplossen dan heb je die kennis ook voor later. Misschien wil je over 4 maanden je huidige klus als referentie gebruiken voor iets nieuws. Als dan door houtje-touwtje werk jouw oplossing twee weken nadat je weg was voor grote problemen zorgde dan kan dit alsnog tegen je werken. Als je werk dan nog steeds staat als een huis heb jij een goede referentie erbij. Dan heb ik het nog niet eens over een stukje mentaliteit/trots/eer in je werk en het gewoon het leukst vinden om een goede oplossing te maken... Toch?

[Red devil]

misfire schreef op zondag 03 december 2006 @ 12:13:
Het probleem oplossen dat app B afsluiten betekent dat de JVM gestopt wordt:

Thanks! Morgen even @ work naar kijken.

Ik zou ook langer kijken dan de horizon van je contract. Je bent ook voor jezelf aan het werk, en als je nu kunt leren hoe je een probleem op een structurele manier kunt oplossen dan heb je die kennis ook voor later. Misschien wil je over 4 maanden je huidige klus als referentie gebruiken voor iets nieuws. Als dan door houtje-touwtje werk jouw oplossing twee weken nadat je weg was voor grote problemen zorgde dan kan dit alsnog tegen je werken. Als je werk dan nog steeds staat als een huis heb jij een goede referentie erbij. Dan heb ik het nog niet eens over een stukje mentaliteit/trots/eer in je werk en het gewoon het leukst vinden om een goede oplossing te maken... Toch?

Helemaal gelijk.

[The - DDD]

Hmm ja, toch vind ik Misfire's manier om een thread te beeindigen niet de meest nette. Punt is namelijk dat je op het moment van interrupten geen idee hebt waar in de executie flow je precies zit in de executie van je run methode.

Meestal zal het wel meevallen, maar ikzelf zou liever de boel gecontroleerder willen onderbreken. En dat zou ikzelf doen middels het zetten van een status vlag zoals al eerder beschreven. Daarmee vraag je aan de thread om te stoppen, in plaats van hem bruut een schop te verkopen. Want een interrupt genereerd toch een exception op het huidige locatie van de executie pointer.

De interrupt execption maakt dat je in principe in een ongedefinieerde toestand komt in de onderbroken thread. Je weet niet waarde code precies was en wat wel en niet af was op het moment van interrupten. Dit hoeft niet erg te zijn, maar ik kan me voorstellen dat er wel situaties te bedenken zijn waar je niet zo blij van wordt. Enkel voor het onderbreken van IO zou ik geneigd zijn om interrupts te gebruiken en dan nog moet je gebruik maken van een interruptable channel.


Wat betreft het gegeven code voorbeeldje van Misfire, gebruik ipv:

Java:

while (!Thread.interrupted()) { // controleren op interrupt vlag.

deze constructie:

Java:

while (!Thread.isInterrupted()) { // controleren op interrupt vlag.

isInterupted zet namelijk niet de interrupted vlag terug naar false. Scheelt weer een statement.

En dat maakt dit statement weer overbodig:

Java:

Thread.currentThread().interrupt(); 

[ Voor 18% gewijzigd door The - DDD op 04-12-2006 11:08 ]

[Alarmnummer]

The - DDD schreef op maandag 04 december 2006 @ 11:04:
Hmm ja, toch vind ik Misfire's manier om een thread te beeindigen niet de meest nette. Punt is namelijk dat je op het moment van interrupten geen idee hebt waar in de executie flow je precies zit in de executie van je run methode.

Je moet niet vergeten dat je een thread die niet in een interruptable methode zit, ook niet geinterrupt gaat worden.

voorbeeld:
Stel je hebt een thread_x die dit uitvoert:

while(true){}

en een andere thread roept thread_x.interrupt aan, dan zal er dus helemaal niets gebeuren. Thread interruption is een cooperative mechanism: dus thread_x moet er zelf ook aan mee werken.

Als een thread de interrupt vlag hangt, dan hangt het volledig af van de ontvangende thread wanneer er iets mee gaat gebeuren. Dus stel dat een thread een half uur lang een niet interruptable methode aan het uitvoeren is, en na 1 minuut wordt de interrupt vlag al gezet, dan zal het minimaal nog 29 minuten duren voordat de thread er op gaat reageren (kan dus ook zijn dat een thread er dus helemaal niets mee doet).

[ Voor 25% gewijzigd door Alarmnummer op 04-12-2006 11:38 ]

[misfire]

The - DDD schreef op maandag 04 december 2006 @ 11:04:
Wat betreft het gegeven code voorbeeldje van Misfire, gebruik ipv:

Java:

while (!Thread.interrupted()) { // controleren op interrupt vlag.

deze constructie:

Java:

while (!Thread.isInterrupted()) { // controleren op interrupt vlag.

Hey thx dat klopt, dat maakt het nóg makkelijker om de interrupt vlag goed te gebruiken. isInterrupted is alleen niet static dus je moet het zo schrijven:

Java:

while (!Thread.currentThread().isInterrupted())

Is nog steeds simpeler.

Zoals Alarmnummer al aangeeft, bij interrupten heeft de geïnterrupte thread nog steeds de controle. Een ander voordeel van interrupten is dat het ook werkt als de thread andere Java threading mechanismen gebruikt, zoals Thread.sleep() oid. Statusvlaggen zijn alleen nodig als je extra state mee wilt geven, bijvoorbeeld een reden waarom geïnterrupt wordt. Dan nog zou ik dat combineren met een interrupt, tenzij je juist niet wilt dat eventuele blocking mechanismen worden interrupt (meestal wil je dat juist wel).

[The - DDD]

Hmm, moet ik toch nog is goed kijken naar hoe interupt werkt. Ik was altijd in de veronderstelling dat er dan simpelweg een (InterruptedException geinjecteerd wordt. Blijk dus een foute aanname te zijn.

We pakken de API docs er bij.
http://java.sun.com/j2se/...g/Thread.html#interrupt()

If this thread is blocked in an invocation of the wait(), wait(long), or wait(long, int) methods of the Object class, or of the join(), join(long), join(long, int), sleep(long), or sleep(long, int), methods of this class, then its interrupt status will be cleared and it will receive an InterruptedException.

Maar dan kom ik weer bij het volgende: Zie de bold gemarkeerde tekst. In een Exception handler voor interrupted is het dus van belang om zelf de interrupt methode nogmaals aan te roepen als de catch handler binnen de executie loop zit en je gebruik wilt maken van de interrupt status.

Edit:
Nog iets, volgens mij is joinen op de worker thread in Misfire's code voorbeeldje niet noodzakelijk zolang de worker thread geen daemon status heeft. Mooi spul, dat multi threading.

[ Voor 11% gewijzigd door The - DDD op 06-12-2006 10:47 ]

[Alarmnummer]

The - DDD schreef op woensdag 06 december 2006 @ 10:44:
In een Exception handler voor interrupted is het dus van belang om zelf de interrupt methode nogmaals aan te roepen als de catch handler binnen de executie loop zit en je gebruik wilt maken van de interrupt status.

Idd. je wilt namelijk niet dat de interrupt flag verloren gaat.

Nog iets, volgens mij is joinen op de worker thread in Misfire's code voorbeeldje niet noodzakelijk zolang de worker thread geen daemon status heeft. Mooi spul, dat multi threading.

Deamon status zegt niet anders dan: lieve vm, als er alleen nog deamon threads in de vm actief zijn, en je wilt afsluiten, dan mag je afsluiten. Dus er is geen relatie tussen join en deamon threads. Dus die join zou moeten werken.

[ Voor 3% gewijzigd door Alarmnummer op 06-12-2006 13:24 ]

[misfire]

The - DDD schreef op woensdag 06 december 2006 @ 10:44:
Hmm, moet ik toch nog is goed kijken naar hoe interupt werkt. Ik was altijd in de veronderstelling dat er dan simpelweg een (InterruptedException geinjecteerd wordt. Blijk dus een foute aanname te zijn.

Hum dit is wel kost voor de Java Programmer 1.4 certificering dus je had het moeten weten... .

We pakken de API docs er bij.
http://java.sun.com/j2se/...g/Thread.html#interrupt()
Maar dan kom ik weer bij het volgende: Zie de bold gemarkeerde tekst. In een Exception handler voor interrupted is het dus van belang om zelf de interrupt methode nogmaals aan te roepen als de catch handler binnen de executie loop zit en je gebruik wilt maken van de interrupt status.

Klopt dus de vereenvoudiging gaat toch niet zo makkelijk als we eerst dachten. Dan vind ik eerlijk gezegd de interrupt later nog expliciet zetten en gewoon met interrupted() testen nog de meest foolproof methode.

Edit:
Nog iets, volgens mij is joinen op de worker thread in Misfire's code voorbeeldje niet noodzakelijk zolang de worker thread geen daemon status heeft. Mooi spul, dat multi threading.

Zoals Alarmnummer al aangeeft: joinen van threads en "daemon threads" zijn twee verschillende dingen. Ik join in het voorbeeld zodat je gegarandeerd als laatste melding de app gestopt melding krijgt (zie commentaar). In het probleem van de TS zou je dit kunnen gebruiken om gecontroleerd app B vanuit app A te stoppen.

[The - DDD]

Ghehe, ok... Met andere woorden. Multi Threading maakt vaak meer kapot dan je lief is. (Als in, je moet echt weten wat je doet als je er mee bezig bent.)

De opmerking over de join was van mijn kant inderdaad niet echt nuttig, daar ik de aanname maakte dat Misfire in de veronderstelling was dat wanneer de main methode eindigt oo kde VM eindigt. Echt lekker een aanname dat iemand een aanname doet. Wat betreft volgordelijkheid is de join methode in ieder geval zeer correct geplaatst.

[ Voor 52% gewijzigd door The - DDD op 08-12-2006 10:29 ]

[Alarmnummer]

The - DDD schreef op vrijdag 08 december 2006 @ 10:27:
Ghehe, ok... Met andere woorden. Multi Threading maakt vaak meer kapot dan je lief is. (Als in, je moet echt weten wat je doet als je er mee bezig bent.)

Daarom moet je ook sowieso proberen om alle concurrency problematiek te verplaatsen in een klein aantal componenten die helemaal van de aanpak op de hoogte is.

Op die manier hou je het lokaal en is het makkelijker te begrijpen (dus ook eenvoudiger om fouten op te lossen). Verder kun je ook beter tegen allerlei liveness problemen optreden.