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