Come deprioritizzare il testrunner Java nei punti di interruzione Eclipse?

Question

Se eseguo il debug di un codice Java multithread in Eclipse, con un RunTest della classe principale e una classe interessante QueueListener.

Ipotesi:

• Quando RunTest viene inizializzata - QueueListener viene eseguito in background.
• Quando RunTest finalizza - QueueListener viene terminata
• C'è un unico metodo in RunTest - con un punto di interruzione in esso
• C'è un unico metodo in QueueListener con un punto di interruzione in esso
• QueueListener può essere eseguito ripetutamente nuovo
• RunTest viene eseguito solo una volta per l'esecuzione (classe genitore)

Quando il debug in Eclipse - entrambi i punti di interruzione vengono in su. Ma Eclipse dà la priorità a RunTest - e devo capovolgerlo manualmente in QueueListener selezionando quel thread nel debugger - e continuo a ripeterlo più e più volte.

C'è un modo per dire a Eclipse che sono più interessato al QueueListener e considerare il testrunner come una priorità inferiore - quando sceglie i punti di interruzione di debug da mostrare?

Answer 1

La risposta può essere trovata nel codice sorgente di eclissi all'interno del metodo ThreadEventHandler. C'è una coda di fili sospesi, come di seguito:

/** 
* Queue of suspended threads to choose from when needing 
* to select a thread when another is resumed. Threads 
* are added in the order they suspend. 
*/ 
private Set fThreadQueue = new LinkedHashSet(); 

seguito, ogni volta che un punto di interruzione viene colpito, il thread sospeso viene aggiunto a questa coda:

protected void handleSuspend(DebugEvent event) { 
    ... 
    queueSuspendedThread(event); 
    ... 
} 

Il metodo per ottenere il prossimo thread sospeso è:

protected synchronized IThread getNextSuspendedThread() { 
    if (!fThreadQueue.isEmpty()) { 
     return (IThread) fThreadQueue.iterator().next(); 
    } 
    return null; 
} 

Quindi la risposta è no, non v'è alcun controllo sull'ordine, sarà rigorosamente nell'ordine che ciascun filo colpisce il punto di interruzione e viene aggiunto alla coda sottostante.

Answer 2

Non è prevista alcuna priorità, ma ciò dipende solo dal comportamento temporale della propria applicazione. Probabilmente i tuoi 2 breakpoint vengono colpiti in un lasso di tempo molto breve, ma sempre nello stesso ordine. E poi eclipse aprirà sempre l'editor (e scorrerà fino al thread) di uno solo di essi (dove non conosco esattamente la strategia scelta, ma indovinerei il primo breakpoint che si è verificato).

Non si desidera veramente che i propri editor/viste siano sempre cambiati durante il debug di un'applicazione multithread e il raggiungimento dei punti di interruzione ogni qualche secondo oppure no?