<AWT Dev> EventQueue changes

[Oleg Sukhodolsky]

On Wed, Sep 24, 2008 at 1:52 PM, Artem Ananiev <Artem.Ananiev at sun.com> wrote:
>
> Oleg Sukhodolsky wrote:
>>
>> On Tue, Sep 16, 2008 at 1:03 PM, Artem Ananiev <Artem.Ananiev at sun.com>
>> wrote:
>>>
>>> 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.
>>
>> What kind of scenarios do you mean?
>
> I'm currently aware of at least 3 requests for this functionality: from
> NetBeans team, from JWebPane team and from JavaWebStart/deploment team. In
> general, in every application with multiple AppContexts controllable event
> pump is required to implement cross-AppContext synchronous calls (like COM).

You know, there is public API for AppContext, so why you want to add
Public API to work with them? ;)
IMHO people who works with AppContexts directly can use private API
for controlled message processing.

Oleg.

>
> Thanks,
>
> Artem
>
>> Thanks, Oleg.
>>>
>>> Thanks,
>>>
>>> Artem
>>>
>>>> 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.
>