Ho un dump del thread di un'applet in esecuzione su JVM 1.6.0_12 in Opera 9.64 Build 10487 - e mostra tre code di eventi! Per quanto ne so, la gestione degli eventi di Java Swing è a thread singolo: questa modifica è stata apportata a un aggiornamento recente?Possono esserci più di una coda di eventi AWT?
Il mio problema è che più code di eventi tenderanno a causare deadlock poiché sono presenti più blocchi rispetto al solo TreeLock della GUI.
Ce ne possono essere più di uno e dipende dal browser. EventQueue documentation dice:
Alcuni browser partizionano applet in basi di codice diverse in contesti separati e stabiliscono muri tra questi contesti. In tale scenario, ci sarà un EventQueue per contesto. Altri browser inseriscono tutte le applet nello stesso contesto, implicando che ci sarà un solo EventQueue globale per tutte le applet. Questo comportamento dipende dall'implementazione.
Sì. In genere ci sarà solo uno Toolkit per Toolkit.getDefaultToolkit, ma più EventQueue s da Toolkit.getSystemEventQueue (che da 1.2.2 in genere ottieni le autorizzazioni per chiamare con successo). C'è magia basata su ThreadGroup e ClassLoader sullo stack per determinare quale EventQueue restituire.
Le partizioni vengono partizionate in base alla loro origine e configurazione. Il modo esatto in cui questo viene eseguito dipende dall'implementazione.
Ora, ciò che probabilmente stai vedendo è una coda di eventi per l'applet e il contesto di sicurezza. Il contesto sicuro gestisce le finestre di dialogo dal plugin stesso. Accettare certificati e cose del genere. Il contesto di sicurezza li mantiene lontani dal codice utente nel contesto dell'applet.
Inoltre, Swing crea un nuovo EventQueue (e thread IIRC) quando viene visualizzata una finestra di dialogo modale, questa coda di eventi è attiva (la precedente è "in attesa") finché non viene chiusa la finestra di dialogo modale.
Tuttavia, non sono sicuro di ciò che accade quando si hanno diversi livelli di finestre di dialogo modali (1 coda principale + 1 coda per finestra di dialogo, o 1 coda principale + 1 coda per tutte le finestre di dialogo).
"Swing crea un nuovo EventQueue (e thread IIRC) quando viene visualizzata una finestra di dialogo modale" In realtà è sbagliato. Ne ho discusso qualche tempo fa con Swing guy e Swing aggiunge solo un nuovo filtro sulla coda degli eventi esistente per filtrare gli eventi provenienti da sorgenti diverse (finestra/componente). Quindi nessun nuovo thread/EQ viene creato per la finestra di dialogo modale. È possibile verificarlo aprendo la finestra di dialogo modale e richiamando il dump del thread prima e dopo l'apertura della finestra di dialogo modale e confrontando lo stack di chiamata del thread AWT. Almeno è come è con l'applicazione Java standard. Non ho ancora controllato il caso dell'applet.
Ok, sarebbe una spiegazione. Ma ho solo una applet quindi è solo una base di codice. Forse l'opera inizia un thread per frame - come per lo script java ... – tigger