> 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 <[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. >
