RE: [rap-dev] ModalContext

["mail.apptech.nichost.ru" <ipavl@xxxxxxxxxxxxxx>]

Hello

> One way to solve these problems could be to take the Synchronizer class
from SWT
It is a good way, I think.

> What I would appreciate most, are JUnit test cases that demonstrate the
use case and currently fail
I'll try to do this. But is there a special project for rap jface tests? Or
I have to create new one?

Thank you,
Igor

-----Original Message-----
From: rap-dev-bounces@xxxxxxxxxxx [mailto:rap-dev-bounces@xxxxxxxxxxx] On
Behalf Of Rudiger Herrmann
Sent: Friday, June 19, 2009 3:55 PM
To: RAP project development-related communication
Subject: Re: [rap-dev] ModalContext

Hi Igor,

as a rule of thumb, if RAP works differently than RCP, it is a bug. 
To fix the bug, it should be fixed in RWT and not in the upper layers
(Workbench, JFace, etc).

I filed this bug for the issues with calling (a)syncExec( null ):
   280829: [Display] calling syncExec/asyncExec(null) behaves
   differently in SWT
   https://bugs.eclipse.org/bugs/show_bug.cgi?id=280829
It should be relatively easy to fix this.

As far as I understand, the second and third remark are related to
synchronization. Your follow-up posting also describes synchronization
issues. Please correct me if I'm wrong.

One way to solve these problems could be to take the Synchronizer class from
SWT and use it instead of the code in UICallBackManager. 
Some additions to the Synchronizer class would be necessary like calling
UICallBackManager#sendUICallBack() from synchExec, etc.
Also sleep/readAndDispatch would need to be reworked to make use of the
Synchronizer methods/lock objects.
Then timerExec() would to need be reworked to fit into the Synchronizer
mechanism. Plus whatever I overlooked so far...
The positive aspect of this way is that we re-use the SWT synchronization
code. The downside is that a lot of the existing code would have to be
changed, which is probably more time-consuming than just fixing the issues
at hand.

What I would appreciate most, are JUnit test cases that demonstrate the use
case and currently fail. With these test cases we could then address one
issue after another.

Cheers,
Rüdiger


mail.apptech.nichost.ru wrote:
> Hello
> 
> It seems that the ModalContext functionality should be reimplemented 
> on RAP (it is ported from RCP now).
> 
> First remark: look at the
> org.eclipse.jface.operation.ModalContext.ModalContextThread.run(). 
> There is a call: "display.asyncExec(null);". On RCP such call have a
special meaning.
> This call causes display thread to wake up.
> 
> Maybe this call ("display.asyncExec(null);") should be removed from 
> the
> org.eclipse.jface.operation.ModalContext.ModalContextThread.run() ?
> Alternative maybe Display#asyncExec should be reimplemented (and also
> syncExec) for the case where runnable is null?
> 
> Second remark:
> 
> There is another part of code in the
> org.eclipse.jface.operation.ModalContext.ModalContextThread.run():
> 
> display.syncExec(new Runnable() {
>   public void run() {
>     // do nothing
>   }
> });
> 
> On RAP this code causes deadlocks with
> org.eclipse.jface.operation.ModalContext.ModalContextThread.block()
method.
> Moreover, there is a problem with
> org.eclipse.rwt.internal.lifecycle.UICallBackManager.SyncRunnable and 
> ModalContext. As you know, SyncRunnable has a block() method, wich 
> blocks the thread that called 
> org.eclipse.rwt.internal.lifecycle.UICallBackManager.addSync(Display,
> Runnable) method. The blocked thread will wait on special lock object 
> until the notification from other thread (with should call 
> SyncRunnable#run method). But when you are using ModalContext the 
> other thread will blocked on runnablesLock.
> 
> I think the problem in the
> org.eclipse.rwt.internal.lifecycle.UICallBackManager.addSync(Display,
> Runnable) method.
> 
> Third remark:
> 
> // Make sure that all events in the asynchronous event queue // are 
> dispatched.
> display.syncExec(new Runnable() {
>   public void run() {
>     // do nothing
>   }
> });
> 
> This code do not the things that declared in comments.
> 
> Last remark: "display.asyncExec(null);" can be implemented correctly, 
> but you have to place additional synchronization string in
> org.eclipse.jface.operation.ModalContext.ModalContextThread.run() to 
> prevent ending of execution
> org.eclipse.jface.operation.ModalContext.ModalContextThread.run() 
> before
> display.sleep() occures in
> org.eclipse.jface.operation.ModalContext.ModalContextThread.block()
method.
> 
> Place
> 
> synchronized (display.getThread()) {
> }
> 
> before
> 
> // Stop event dispatching
> continueEventDispatching = false;
> 
> The display.getThread() returns UIThread instance. So it will be 
> locked until the switchThread notification from display.sleap() method.
> 
> Thank you, Igor
> 
> 
> _______________________________________________
> rap-dev mailing list
> rap-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rap-dev
_______________________________________________
rap-dev mailing list
rap-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rap-dev