Oleg Sukhodolsky wrote:
3. pumpEvents() API is made public, probably with some minor changes.
what use cases you want to address by this new API?
There are several tens of votes for all the related bugs. One more
argument is that all the modern toolkits (Win32, GTK, SWT) have this API
implemented, while AWT/Swing still misses it.
I also constantly face with scenarios, when some developer needs to
start a nested event pump and use a modal dialog for this, which looks
quite ugly and unstable.
Thanks,
Artem
Regards, Oleg.
On Thu, Sep 11, 2008 at 12:10 PM, Artem Ananiev <[EMAIL PROTECTED]> wrote:
Hi, Oleg,
Oleg Sukhodolsky wrote:
On Tue, Sep 9, 2008 at 3:55 PM, Artem Ananiev <[EMAIL PROTECTED]>
wrote:
Hi, AWT team,
there are several issues related to EventQueue class with a long history.
The number of user votes constantly grows, so I think it would be fine if
we
can get them fixed in some nearest future.
The list of bugs include (but not limited to):
6424157: java.awt.EventQueue push/pop might cause threading issues
6542185: Threading issues with java.awt.EventQueue.push/pop
(closed as not a defect, but some of described problems still exist)
4913324: Deadlock when using two event queues.
4516924: Request public access to pumpEvents(Conditional) type
functionality.
6727884: Some Uncaught Exceptions are no longer getting sent to the
Uncaught
Exception Handlers
Some of the described problems don't look related to each other, however
after a closer look I found they really do. That's why I listed them here
altogether, and would like to discuss some possible improvements:
1. Synchronization changes. Most of the problems with push/pop are caused
by
imperfect synchronization in EventQueue. Currently, all the actions like
postEvent() or getNextEvent() are transferred back and forth in the stack
of
event queues, and each queue is accessed in its 'synchronized' block.
Instead, a single lock looks more correct here.
2. EventDispatchThread lifecycle. It is a known fact, that event dispatch
thread may die for some reason (for example, because of unhandled
exception). When a new event comes, new EDT is created. Another case when
EDT is switched is push/pop methods: when a new EQ is pushed/popped, a
new
EDT is created.
I'm sure these changes of current dispatch thread is not what developers
expect. Swing is considered as single-threaded toolkit, but it is really
not...
3. Controllable event pump. This is what developers have been requesting
for
at least 8 years. With the current API this task cannot be solved, and
all
the external libs like Foxtrot are really just hacks and depend on JDK
internals.
From technical point of view, controllable event pump is just a several
lines of code changes: we only need to make public the code which is used
for modality event pumps.
----
I have a prototype fix with all the three items implemented. Still, it
would
be fine to hear what all AWT developers think about proposed changes.
I see list of problems, but do not see list of proposed changes :(
Did I miss something?
You're right, the changes are not included, my fault... Here they are:
1. A single lock is introduced to handle all the EQ operations like push,
pop, getNextEvent, etc. instead of locking all EQ objects one by one, if
several.
2. EventDispatchThread is reused as much as possible. When a new EQ is
pushed, it uses the old EDT instead of creating a new one. The same is true
for pop().
3. pumpEvents() API is made public, probably with some minor changes.
Thanks,
Artem
With best regards, Oleg.
