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  |
 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  |
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 #304566 is a reply to message #304559] |
Sat, 10 June 2006 14:20 |
| 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 |
| 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 |
| 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 #305096 is a reply to message #305090] |
Thu, 22 June 2006 17:42 |
| 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 #305136 is a reply to message #305100] |
Fri, 23 June 2006 13:46 |
| 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."
|
|
|
Goto Forum:
Current Time: Thu Apr 25 03:53:34 GMT 2024
Powered by FUDForum. Page generated in 0.04088 seconds |
] 
Search
Help
Register
Login
Home
