RE: [rap-dev] ModalContext

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

Hi

I think I found a real problem. Look at the implementaion of Display#sleep.
You will see that this method calls Display#getMessageCount which calls
org.eclipse.swt.widgets.Synchronizer.getMessageCount(). Last method
synchronized with special object: messageLock. Look at the Display#syncExec.
This method calls org.eclipse.swt.widgets.Synchronizer.syncExec(Runnable),
which calls org.eclipse.swt.widgets.Synchronizer.addLast(RunnableLock) which
synchronized on the same object.

We can see two differences:
1) On RCP event dispatching never stops until you add a sync runnable (if we
have concurrent calls from two different threads). But on RAP the appearance
is different. On RCP Display#sleep synchronized by the same object
(messageLock) as Display#syncExec.

2) On RCP Display#syncExec resumes event dispatching. On RAP is not (look at
the org.eclipse.swt.widgets.Synchronizer.addLast(RunnableLock) method -
there is a call of display.wakeThread () wich will resume event dispatching.

It is very important to fix this problem to me. And I can try to fix it
correctly. But I have to ask somebody of RAP developers to told me about RAP
team vision on this problem. What way is the best way to fix this bug?

Thank you,
Igor 

-----Original Message-----
From: rap-dev-bounces@xxxxxxxxxxx [mailto:rap-dev-bounces@xxxxxxxxxxx] On
Behalf Of mail.apptech.nichost.ru
Sent: Tuesday, June 16, 2009 2:12 PM
To: 'RAP project development-related communication'
Subject: [rap-dev] ModalContext

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