[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [rap-dev] ModalContext
|
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