Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Platform » Probably simple problem with Job and asyncExec()
Probably simple problem with Job and asyncExec() [message #304559] Fri, 09 June 2006 22:09 Go to next message
Paul E. Keyser is currently offline Paul E. Keyser
Messages: 878
Registered: July 2009
Senior Member
R3.1.2, WinXP

So, I've read the online docs about Job and workspace-concurrency and so on, several times. I'm
trying to (a) run a Job, in background, to do some calculation, which then (b) later (once the Job
is finished) needs to update the GUI. (My situation is very like the way decorators get added to the
PackageExplorer, but that code is pretty opaque.)

The docs and various threads on the newsgroup recommend using "Display.asyncExec()" to accomplish
the GUI updating. But when I try that, it fails *every time* (rare to get a universal behavior with
threads, eh?) -- because, if I use the Display.getDefault(), I get an invalid thread access; ditto
if I provide the Job with a Display pointer at creation-time. So *how* do you get
Display.asyncExec() to actually work?

thanks,
Paul
Re: Probably simple problem with Job and asyncExec() [message #304560 is a reply to message #304559] Fri, 09 June 2006 22:56 Go to previous messageGo to next message
Eclipse User
Originally posted by: richkulp.us.NO_SPAM.ibm.com

Is it the Display.getDefault() that is throwing the invalid thread
access or is it the display.aSyncExec(). Actually neither should throw
this. So please check very carefully what call is actually throwing this.

Appending back a stack trace from the InvalidThreadAccess exception
would be very helpful.

--
Thanks,
Rich Kulp
Re: Probably simple problem with Job and asyncExec() [message #304562 is a reply to message #304560] Sat, 10 June 2006 03:14 Go to previous messageGo to next message
Paul E. Keyser is currently offline Paul E. Keyser
Messages: 878
Registered: July 2009
Senior Member
It was Display.getCurrent() that was throwing; when I tried Display.getDefault(), seems to work --
of course, now it is *slower* than with no threads at all!

thanks,
Paul
Re: Probably simple problem with Job and asyncExec() [message #304563 is a reply to message #304560] Sat, 10 June 2006 03:46 Go to previous messageGo to next message
Paul E. Keyser is currently offline Paul E. Keyser
Messages: 878
Registered: July 2009
Senior Member
Rich Kulp wrote:

> Is it the Display.getDefault() that is throwing the invalid thread
> access or is it the display.aSyncExec(). Actually neither should throw
> this. So please check very carefully what call is actually throwing this.
>
> Appending back a stack trace from the InvalidThreadAccess exception
> would be very helpful.
>
Hmm -- it came back, even with Display.getDefault():

java.lang.NullPointerException
at org.eclipse.swt.widgets.Display.asyncExec(Display.java:586)
at com.ibm.sai.saw2.editors.semanticViewer.SatisfiabilityJob.ru n(SatisfiabilityJob.java:47)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76)

(That is the whole stack)
SatisfiabilityJob.java:47 =>
Display.getDefault().asyncExec(new Runnable() {
public void run() {
_viewer.refresh();
_viewer.expandAll();
}
});

So -- what is that NPE caused by?

thanks,
Paul
Re: Probably simple problem with Job and asyncExec() [message #304566 is a reply to message #304559] Sat, 10 June 2006 14:20 Go to previous messageGo to next message
Eclipse User
Originally posted by: lamont_gilbert.rigidsoftware.com

Yes jobs and concurrency is VERY confusing.

Paul Keyser wrote:

> R3.1.2, WinXP
>
> So, I've read the online docs about Job and workspace-concurrency and so
> on, several times. I'm trying to (a) run a Job, in background, to do some
> calculation, which then (b) later (once the Job is finished) needs to
> update the GUI. (My situation is very like the way decorators get added to
> the PackageExplorer, but that code is pretty opaque.)
>

It depends. A job is good for decorator updating. If its updating more
than decorators, like changing the model, then I probably wouldn't use a
job.


> The docs and various threads on the newsgroup recommend using
> "Display.asyncExec()" to accomplish the GUI updating. But when I try that,
> it fails *every time* (rare to get a universal behavior with threads, eh?)
> -- because, if I use the Display.getDefault(), I get an invalid thread
> access; ditto if I provide the Job with a Display pointer at
> creation-time. So *how* do you get Display.asyncExec() to actually work?
>
> thanks,
> Paul


The tricky part is that you often can't get the Display unless you are in
the UI thread. So your calls to getDisplay can return null sometimes. And
sometimes will throw an illegal access exception.

The job should not update your view directly. In the process of your jobs
work, if this causes the view to need updating, the view probably should
somehow have registered a listener. and when the view hears that it needs
to update itself, the view should get the data to do the update, and call
syncExec or asyncExec as you need. The view will know better if it should
actually update itself, or if it should not because its disposed or closing
or anything else.

Its a simple problem you have but the solution is not so simple.


--
Respectfully,

CL Gilbert
"Verily, verily, I say unto you, He that entereth not by the door() into the
sheepfold{}, but climbeth up some other *way, the same is a thief and a
robber."
Re: Probably simple problem with Job and asyncExec() [message #304606 is a reply to message #304563] Mon, 12 June 2006 15:06 Go to previous messageGo to next message
Eclipse User
Originally posted by: richkulp.us.NO_SPAM.ibm.com

I don't see how it could happen. I don't know what version you are
using, but neither 3.1 nor 3.2 has anything at line 586 in Display. But
in asyncExec there is only one place that could throw an NPE, and that
is when the field "synchronizer" is null. But there is only one small
(very-very-small) window where this could happen. It could happen only
if during dispose (shutdown) that the job was trying to do an async
exec. There is a small window between where "syncrhonizer" is set to
null and where the isDisposed flag is set. The asyncExec does an
isDisposed check before going ahead accessing the synchronizer. But if
in the process of dispose it may of gotton far enough to null the
synchronizer but not far enough to set the isDisposed flag. But this is
only a few lines of code apart. It would be a very rare race condition
to hit this!

Paul Keyser wrote:
> Rich Kulp wrote:
>
>> Is it the Display.getDefault() that is throwing the invalid thread
>> access or is it the display.aSyncExec(). Actually neither should throw
>> this. So please check very carefully what call is actually throwing this.
>>
>> Appending back a stack trace from the InvalidThreadAccess exception
>> would be very helpful.
>>
> Hmm -- it came back, even with Display.getDefault():
>
> java.lang.NullPointerException
> at org.eclipse.swt.widgets.Display.asyncExec(Display.java:586)
> at
> com.ibm.sai.saw2.editors.semanticViewer.SatisfiabilityJob.ru n(SatisfiabilityJob.java:47)
>
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76)
>
> (That is the whole stack)
> SatisfiabilityJob.java:47 =>
> Display.getDefault().asyncExec(new Runnable() {
> public void run() {
> _viewer.refresh();
> _viewer.expandAll();
> }
> });
>
> So -- what is that NPE caused by?
>
> thanks,
> Paul

--
Thanks,
Rich Kulp
Re: Probably simple problem with Job and asyncExec() [message #304613 is a reply to message #304606] Mon, 12 June 2006 20:24 Go to previous messageGo to next message
Eclipse User
Originally posted by: lamont_gilbert.rigidsoftware.com

Rich Kulp wrote:

> I don't see how it could happen. I don't know what version you are
> using, but neither 3.1 nor 3.2 has anything at line 586 in Display. But
> in asyncExec there is only one place that could throw an NPE, and that
> is when the field "synchronizer" is null. But there is only one small
> (very-very-small) window where this could happen. It could happen only
> if during dispose (shutdown) that the job was trying to do an async
> exec. There is a small window between where "syncrhonizer" is set to
> null and where the isDisposed flag is set. The asyncExec does an
> isDisposed check before going ahead accessing the synchronizer. But if
> in the process of dispose it may of gotton far enough to null the
> synchronizer but not far enough to set the isDisposed flag. But this is
> only a few lines of code apart. It would be a very rare race condition
> to hit this!
>
> Paul Keyser wrote:
>> Rich Kulp wrote:
>>
>>> Is it the Display.getDefault() that is throwing the invalid thread
>>> access or is it the display.aSyncExec(). Actually neither should throw
>>> this. So please check very carefully what call is actually throwing
>>> this.
>>>
>>> Appending back a stack trace from the InvalidThreadAccess exception
>>> would be very helpful.
>>>
>> Hmm -- it came back, even with Display.getDefault():
>>
>> java.lang.NullPointerException
>> at org.eclipse.swt.widgets.Display.asyncExec(Display.java:586)
>> at
>>
com.ibm.sai.saw2.editors.semanticViewer.SatisfiabilityJob.ru n(SatisfiabilityJob.java:47)
>>
>> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76)
>>
>> (That is the whole stack)
>> SatisfiabilityJob.java:47 =>
>> Display.getDefault().asyncExec(new Runnable() {
>> public void run() {
>> _viewer.refresh();
>> _viewer.expandAll();
>> }
>> });
>>
>> So -- what is that NPE caused by?
>>
>> thanks,
>> Paul
>



I used to get this for two reasons. 1 when bench was shutting down would
cause some stuff to close and cause a refresh which tried to happen after
control was disposing and so control returned null Display. Also there are
times if you ask for a display from the wrong thread you get NPE as opposed
to illegal thread access or whatever.

But I don't get these anymore either because I code better or eclipse does.


--
Respectfully,

CL Gilbert
"Verily, verily, I say unto you, He that entereth not by the door() into the
sheepfold{}, but climbeth up some other *way, the same is a thief and a
robber."
Re: Probably simple problem with Job and asyncExec() [message #304758 is a reply to message #304606] Wed, 14 June 2006 15:43 Go to previous messageGo to next message
Paul E. Keyser is currently offline Paul E. Keyser
Messages: 878
Registered: July 2009
Senior Member
Rich Kulp wrote:
> I don't see how it could happen. I don't know what version you are
> using, but neither 3.1 nor 3.2 has anything at line 586 in Display.

Well, I have 3.1.2, and line 586 of Display is:
public void asyncExec (Runnable runnable) {
if (isDisposed ()) error (SWT.ERROR_DEVICE_DISPOSED);
synchronizer.asyncExec (runnable); <<<<<<<<<<<<<<<<<<<<<< 586
}


> But
> in asyncExec there is only one place that could throw an NPE, and that
> is when the field "synchronizer" is null. But there is only one small
> (very-very-small) window where this could happen. It could happen only
> if during dispose (shutdown) that the job was trying to do an async
> exec. There is a small window between where "syncrhonizer" is set to
> null and where the isDisposed flag is set. The asyncExec does an
> isDisposed check before going ahead accessing the synchronizer. But if
> in the process of dispose it may of gotton far enough to null the
> synchronizer but not far enough to set the isDisposed flag. But this is
> only a few lines of code apart. It would be a very rare race condition
> to hit this!
>
Indeed I have only seen it once; it *could* have been during shutdown (was last thing in log), as CL
Gilbert suggested.

thanks,
Paul
Re: Probably simple problem with Job and asyncExec() [message #305090 is a reply to message #304613] Thu, 22 June 2006 15:27 Go to previous messageGo to next message
Paul E. Keyser is currently offline Paul E. Keyser
Messages: 878
Registered: July 2009
Senior Member
CL [dnoyeb] Gilbert wrote:

> I used to get this for two reasons. 1 when bench was shutting down would
> cause some stuff to close and cause a refresh which tried to happen after
> control was disposing and so control returned null Display. Also there are
> times if you ask for a display from the wrong thread you get NPE as opposed
> to illegal thread access or whatever.
>
> But I don't get these anymore either because I code better or eclipse does.
>
Got it again, and probably on shutdown:

java.lang.NullPointerException
at org.eclipse.swt.widgets.Display.asyncExec(Display.java:586)
at com.ibm.sai.saw2.editors.semantic.viewer.impl.Satisfiability Job.run(SatisfiabilityJob.java:56)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76)

Looks like this *is* that narrow window Rich K was talking about.

Paul
Re: Probably simple problem with Job and asyncExec() [message #305096 is a reply to message #305090] Thu, 22 June 2006 17:42 Go to previous messageGo to next message
Eclipse User
Originally posted by: lamont_gilbert.rigidsoftware.com

Paul Keyser wrote:

> CL [dnoyeb] Gilbert wrote:
>
>> I used to get this for two reasons. 1 when bench was shutting down would
>> cause some stuff to close and cause a refresh which tried to happen after
>> control was disposing and so control returned null Display. Also there
>> are times if you ask for a display from the wrong thread you get NPE as
>> opposed to illegal thread access or whatever.
>>
>> But I don't get these anymore either because I code better or eclipse
>> does.
>>
> Got it again, and probably on shutdown:
>
> java.lang.NullPointerException
> at org.eclipse.swt.widgets.Display.asyncExec(Display.java:586)
> at
>
com.ibm.sai.saw2.editors.semantic.viewer.impl.Satisfiability Job.run(SatisfiabilityJob.java:56)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76)
>
> Looks like this *is* that narrow window Rich K was talking about.
>
> Paul

I believe when I get the display I check if its disposed first. Also that
its not null. or maybe thats on the shell. Something like that.


--
Respectfully,

CL Gilbert
"Verily, verily, I say unto you, He that entereth not by the door() into the
sheepfold{}, but climbeth up some other *way, the same is a thief and a
robber."
Re: Probably simple problem with Job and asyncExec() [message #305100 is a reply to message #305096] Thu, 22 June 2006 18:52 Go to previous messageGo to next message
Paul E. Keyser is currently offline Paul E. Keyser
Messages: 878
Registered: July 2009
Senior Member
CL [dnoyeb] Gilbert wrote:

> I believe when I get the display I check if its disposed first. Also that
> its not null. or maybe thats on the shell. Something like that.
>
Right -- but the Display is not null, and it is rather (on line 586) that a field of Display, the
"Synchronizer", is null. ... But maybe that is a sign that the Display is disposed? I'll add such a
check ...

Paul
Re: Probably simple problem with Job and asyncExec() [message #305136 is a reply to message #305100] Fri, 23 June 2006 13:46 Go to previous message
Eclipse User
Originally posted by: lamont_gilbert.rigidsoftware.com

Paul Keyser wrote:

> CL [dnoyeb] Gilbert wrote:
>
>> I believe when I get the display I check if its disposed first. Also
>> that
>> its not null. or maybe thats on the shell. Something like that.
>>
> Right -- but the Display is not null, and it is rather (on line 586) that
> a field of Display, the "Synchronizer", is null. ... But maybe that is a
> sign that the Display is disposed? I'll add such a check ...
>
> Paul


That looks like a bug then. isDisposed is not guaranteeing that it wont
dispose right after you ask the question. it probably will catch the error
but not the root of the issue. I think there are jobs that know when they
shouldn't run as well.


--
Respectfully,

CL Gilbert
"Verily, verily, I say unto you, He that entereth not by the door() into the
sheepfold{}, but climbeth up some other *way, the same is a thief and a
robber."
Previous Topic:rcstemplates with Eclipse cvs checkins
Next Topic:No notification of PRE_BUILD for INCREMENTAL_BUILD
Goto Forum:
  


Current Time: Wed Oct 22 06:31:31 GMT 2014

Powered by FUDForum. Page generated in 0.02207 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software