Hello Yes, it is the same bug
Thank you, Igor -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Rudiger Herrmann Sent: Sunday, April 19, 2009 1:46 AM To: RAP project development-related communication Subject: Re: [rap-dev] UICallBackManager created this bug since I am not entirely sure that the issue is the same as reported in bug 220981. 272811: Display#addSync() waits infinitely under certain circumstances https://bugs.eclipse.org/bugs/show_bug.cgi?id=272811 There is a patch that should solve the problem and also changes the sync-lock in addSync(). Could you try it out and give feedback, either here or on the bug? Rüdiger Rüdiger Herrmann wrote: > Hi Igor, > > thanks for the suggestion. Though I don't quite understand how the > while(!isLocked) loop solves the problem. > Could you explain that? Or attach a patch to the bug mentioned before? > > Thanks > Rüdiger > > > mail.apptech.nichost.ru wrote: >> Hello >> Maybe I can do something like this: >> >> 1) Add boolean field SyncRunnable#isLocked >> >> 2) Create runLocked method in SyncRunnable: >> >> void runLocked() { >> synchronized( lock ) { >> while(!isLocked) { >> try { >> wait(); >> } catch( InterruptedException e ) { >> // Do nothing >> } >> } >> isLocked = false; >> } >> super.run(); >> synchronized( lock ) { >> lock.notifyAll(); >> } >> } >> >> 3) In UICallBackManager#processNextRunnableInUIThread change >> runnable.run() >> to if (runnable instanceof SyncRunnable) { >> ( ( SyncRunnable )runnable ).runLocked(); >> } >> else { >> runnable.run(); >> } >> >> >> Whis this changes I can solve my problem (the problem that I >> described). I tried not to change logic for other types of runnables, >> so the code listed above is not very clean, but it works. >> >> Thank you, Igor >> >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Rudiger Herrmann >> Sent: Wednesday, April 08, 2009 1:51 PM >> To: RAP project development-related communication >> Subject: Re: [rap-dev] UICallBackManager >> >> >> Igor, >> >> unfortunately fixing this issue isn't that easy. As stated in the >> comment, synchronizing on runnablesLock may lead to a deadlock. >> See also this bugzilla entry: >> 220981: Fix synchronization Problem in UICallBackManager#addSync() >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=220981 >> >> Cheers, >> Rüdiger >> >> mail.apptech.nichost.ru wrote: >>> Hello >>> >>> I have a question about UICallBackManager. There are a set of >>> functions that synchronized with runnablesLock, but not the addSync >>> function. Is it correct? >>> >>> I reproduced an incorrect situation. I have a thread that locked in >>> SyncRunnable#block method, but I have an empty >>> UICallBackManager#runnables list. It seems that the corresponding >>> SyncRunnable of my thread was removed from >>> UICallBackManager#runnables before my runnable was blocked in >>> SyncRunnable#block method. >>> >>> Is it a bug and can I fix this bug by adding synchronization of >>> runnablesLock? Threre is a comment that notifies about possible >>> problems with such aproach. >>> >>> Thank you, >>> Igor >>> >>> >>> _______________________________________________ >>> rap-dev mailing list >>> [email protected] >>> https://dev.eclipse.org/mailman/listinfo/rap-dev >> _______________________________________________ >> rap-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/rap-dev >> >> >> _______________________________________________ >> rap-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/rap-dev > _______________________________________________ rap-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/rap-dev _______________________________________________ rap-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/rap-dev
