<AWT Dev> EventQueue changes

[Oleg Sukhodolsky]

> 3. pumpEvents() API is made public, probably with some minor changes.

what use cases you want to address by this new API?

Regards, Oleg.

On Thu, Sep 11, 2008 at 12:10 PM, Artem Ananiev <Artem.Ananiev at sun.com> wrote:
> Hi, Oleg,
>
> Oleg Sukhodolsky wrote:
>>
>> On Tue, Sep 9, 2008 at 3:55 PM, Artem Ananiev <Artem.Ananiev at sun.com>
>> 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.
>