On Wed, Sep 24, 2008 at 1:52 PM, Artem Ananiev <[EMAIL PROTECTED]> wrote: > > Oleg Sukhodolsky wrote: >> >> On Tue, Sep 16, 2008 at 1:03 PM, Artem Ananiev <[EMAIL PROTECTED]> >> 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 <[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. >
