< prev index next >

src/java.desktop/share/classes/java/awt/ActiveEvent.java

Print this page

        

*** 26,48 **** package java.awt; /** * An interface for events that know how to dispatch themselves. * By implementing this interface an event can be placed upon the event ! * queue and its <code>dispatch()</code> method will be called when the event ! * is dispatched, using the <code>EventDispatchThread</code>. * <p> * This is a very useful mechanism for avoiding deadlocks. If * a thread is executing in a critical section (i.e., it has entered * one or more monitors), calling other synchronized code may * cause deadlocks. To avoid the potential deadlocks, an ! * <code>ActiveEvent</code> can be created to run the second section of * code at later time. If there is contention on the monitor, * the second thread will simply block until the first thread * has finished its work and exited its monitors. * <p> ! * For security reasons, it is often desirable to use an <code>ActiveEvent</code> * to avoid calling untrusted code from a critical thread. For * instance, peer implementations can use this facility to avoid * making calls into user code from a system thread. Doing so avoids * potential deadlocks and denial-of-service attacks. * --- 26,48 ---- package java.awt; /** * An interface for events that know how to dispatch themselves. * By implementing this interface an event can be placed upon the event ! * queue and its {@code dispatch()} method will be called when the event ! * is dispatched, using the {@code EventDispatchThread}. * <p> * This is a very useful mechanism for avoiding deadlocks. If * a thread is executing in a critical section (i.e., it has entered * one or more monitors), calling other synchronized code may * cause deadlocks. To avoid the potential deadlocks, an ! * {@code ActiveEvent} can be created to run the second section of * code at later time. If there is contention on the monitor, * the second thread will simply block until the first thread * has finished its work and exited its monitors. * <p> ! * For security reasons, it is often desirable to use an {@code ActiveEvent} * to avoid calling untrusted code from a critical thread. For * instance, peer implementations can use this facility to avoid * making calls into user code from a system thread. Doing so avoids * potential deadlocks and denial-of-service attacks. *
< prev index next >