-
Bug
-
Resolution: Fixed
-
P3
-
1.2.0
-
1.2fcs
-
generic
-
solaris_2.5
-
Not verified
We've received numerous requests for multiple event queues in the AWT,
and if we're to do it in 1.2, now is the time. We don't dare do such
a significant change a few months from now.
To implement multiple event queues, we really need to re-enable multiple
AppContexts, which was disabled by Tom on February 25th until the key
could be computed reliably.
The key for AppContexts was the security context. My current
understanding of the problem was that if we were in priveleged code, the
security context was that of the priveleged code, so the AppContext was
computed incorrectly.
It seems to me that the needs of an AppContext key are different from
that of security. When computing the AppContext, we are concerned with
the instance of the earliest AppContext-controlling object on the call
stack. Entering priveleged code shouldn't affect this at all.
I anticipate that we'll need a method in the VM similar to
JVM_GetStackAccessControlContext() to do this for us, which we'll use
to find the current AppContext.
This is a significant departure from the earlier AppContext key based
on security context, but I think this makes sense. My other
concern is performance. It's hard to compete with stubbed code for
performance. :-)
and if we're to do it in 1.2, now is the time. We don't dare do such
a significant change a few months from now.
To implement multiple event queues, we really need to re-enable multiple
AppContexts, which was disabled by Tom on February 25th until the key
could be computed reliably.
The key for AppContexts was the security context. My current
understanding of the problem was that if we were in priveleged code, the
security context was that of the priveleged code, so the AppContext was
computed incorrectly.
It seems to me that the needs of an AppContext key are different from
that of security. When computing the AppContext, we are concerned with
the instance of the earliest AppContext-controlling object on the call
stack. Entering priveleged code shouldn't affect this at all.
I anticipate that we'll need a method in the VM similar to
JVM_GetStackAccessControlContext() to do this for us, which we'll use
to find the current AppContext.
This is a significant departure from the earlier AppContext key based
on security context, but I think this makes sense. My other
concern is performance. It's hard to compete with stubbed code for
performance. :-)
- relates to
-
JDK-4152133 Win32 peers should never call user code on the AWT-Windows thread
-
- Closed
-
-
JDK-4152184 Motif peers should never call user code on the AWT-Motif thread
-
- Closed
-
-
JDK-4159054 sun.awt.AppContext needs a dispose()
-
- Closed
-
-
JDK-4156853 appletviewer should allow applets access to their EventQueue objects
-
- Closed
-
-
JDK-4142012 1.2 Beta 4: Multiple AWT event queues not supported
-
- Closed
-