Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "FAQ How do I find out whether a particular job is running?"

 
m
Line 1: Line 1:
If you have a reference to a job instance, you can use the method  
+
If you have a reference to a job instance, you can use the method <tt>Job.getState</tt> to find out whether it is running. Note that owing to the asynchronous nature of jobs, the result may be invalid by the time the method returns.  For example, a job may be running at the time the method is called but may finish running between the time you invoke <tt>getState</tt> and the time you check its return value.  For this reason, you should generally avoid relying too much on the result of this method.   
<tt>Job.getState</tt> to find out whether it is running. Note that  
+
owing to the asynchronous nature of jobs, the result may be invalid by  
+
the time the method returns.  For example, a job may be running at  
+
the time the method is called but may finish running between the  
+
time you invoke <tt>getState</tt> and the time you check its return
+
value.  For this reason, you should generally avoid relying too much on the result
+
of this method.   
+
  
 +
The job infrastructure makes things easier for you by generally being very tolerant of methods called at the wrong time.  For example, if you call <tt>wakeUp</tt> on a job that is not sleeping or <tt>cancel</tt> on a job that is already finished, the request is silently ignored.  Thus, you can generally  forgo the state check and simply try the method you want to call. 
 +
For example, you do not need to do this:
  
 
The job infrastructure makes things easier for you by generally
 
being very tolerant of methods called at the wrong time.  For example, if you call
 
<tt>wakeUp</tt> on a job that is not sleeping or <tt>cancel</tt> on a job that
 
is already finished, the request is silently ignored.  Thus, you can generally
 
forgo the state check and simply try the method you want to call. 
 
For example, you do not need to do this:
 
 
<pre>
 
<pre>
 
   if (job.getState() == Job.NONE)
 
   if (job.getState() == Job.NONE)
 
       job.schedule();
 
       job.schedule();
 
</pre>
 
</pre>
Instead, you can invoke <tt>job.schedule()</tt> immediately.  If the job is already
 
scheduled or sleeping, the schedule request will be ignored.  If the job
 
is currently running, it will be rescheduled as soon as it completes
 
  
 +
Instead, you can invoke <tt>job.schedule()</tt> immediately.  If the job is already scheduled or sleeping, the schedule request will be ignored.  If the job is currently running, it will be rescheduled as soon as it completes
  
 +
If you need to be certain of when a job enters a particular state, register a job change listener on the job.  Listeners are notified whenever jobs change state, so you can be sure that you will never miss a state change this way.  Although the job may have changed state again by the time your listener is called, you are guaranteed that a given job listener will not receive  multiple events concurrently or out of order.
  
 +
If you do not have a job reference, you can search for it by using the method <tt>IJobManager.find</tt>.  This method will find only job instances that are running, waiting, or sleeping.  To give a concrete example, the Eclipse IDE uses this method when the user launches an application. The method searches for the autobuild job and, if it is running, waits for autobuild to complete before launching the application.  Here is a snippet that illustrates this behavior; the actual code is more complex because it first consults a preference setting and might decide to prompt the user:
  
If you need
 
to be certain of when a job enters a particular state, register a job change
 
listener on the job.  Listeners are notified whenever jobs change state,
 
so you can be sure that you will never miss a state change this way.  Although
 
the job may have changed state again by the time your listener is called,
 
you are guaranteed that a given job listener will not receive
 
multiple events concurrently or out of order.
 
 
 
 
 
If you do not have a job reference, you can search for it by using the
 
method <tt>IJobManager.find</tt>.  This method will find only
 
job instances that are running, waiting, or sleeping.  To give a concrete
 
example, the Eclipse IDE uses this method when the user launches an application.
 
The method searches for the autobuild job and, if it is running, waits for autobuild
 
to complete before launching the application.  Here is a snippet that illustrates this
 
behavior; the actual code is more complex because it first consults a preference
 
setting and might decide to prompt the user:
 
 
<pre>
 
<pre>
 
   IJobManager jobMan = Platform.getJobManager();
 
   IJobManager jobMan = Platform.getJobManager();
Line 52: Line 21:
 
       build[0].join();
 
       build[0].join();
 
</pre>
 
</pre>
Again, it is safe to call <tt>join</tt> here without checking whether
 
the job is still running. The <tt>join</tt> method will return immediately
 
in this case.
 
 
 
 
 
  
 +
Again, it is safe to call <tt>join</tt> here without checking whether  the job is still running. The <tt>join</tt> method will return immediately  in this case.
  
 
== See Also: ==
 
== See Also: ==
 +
[[FAQ Does the platform have support for concurrency?]]
 +
[[FAQ What is the purpose of job families?]]
 +
[[FAQ How can I track the lifecycle of jobs?]]
  
 
+
{{Template:FAQ_Tagline}}
[[FAQ_Does_the_platform_have_support_for_concurrency%3F]]
+
 
+
 
+
[[FAQ_What_is_the_purpose_of_job_families%3F]]
+
 
+
 
+
[[FAQ_How_can_I_track_the_lifecycle_of_jobs%3F]]
+
 
+
<hr><font size=-2>This FAQ was originally published in [http://www.eclipsefaq.org Official Eclipse 3.0 FAQs]. Copyright 2004, Pearson Education, Inc. All rights reserved. This text is made available here under the terms of the [http://www.eclipse.org/legal/epl-v10.html Eclipse Public License v1.0].</font>
+

Revision as of 23:17, 1 June 2006

If you have a reference to a job instance, you can use the method Job.getState to find out whether it is running. Note that owing to the asynchronous nature of jobs, the result may be invalid by the time the method returns. For example, a job may be running at the time the method is called but may finish running between the time you invoke getState and the time you check its return value. For this reason, you should generally avoid relying too much on the result of this method.

The job infrastructure makes things easier for you by generally being very tolerant of methods called at the wrong time. For example, if you call wakeUp on a job that is not sleeping or cancel on a job that is already finished, the request is silently ignored. Thus, you can generally forgo the state check and simply try the method you want to call. For example, you do not need to do this:

   if (job.getState() == Job.NONE)
      job.schedule();

Instead, you can invoke job.schedule() immediately. If the job is already scheduled or sleeping, the schedule request will be ignored. If the job is currently running, it will be rescheduled as soon as it completes

If you need to be certain of when a job enters a particular state, register a job change listener on the job. Listeners are notified whenever jobs change state, so you can be sure that you will never miss a state change this way. Although the job may have changed state again by the time your listener is called, you are guaranteed that a given job listener will not receive multiple events concurrently or out of order.

If you do not have a job reference, you can search for it by using the method IJobManager.find. This method will find only job instances that are running, waiting, or sleeping. To give a concrete example, the Eclipse IDE uses this method when the user launches an application. The method searches for the autobuild job and, if it is running, waits for autobuild to complete before launching the application. Here is a snippet that illustrates this behavior; the actual code is more complex because it first consults a preference setting and might decide to prompt the user:

   IJobManager jobMan = Platform.getJobManager();
   Job[] build = jobMan.find(ResourcesPlugin.FAMILY_AUTO_BUILD); 
   if (build.length == 1)
      build[0].join();

Again, it is safe to call join here without checking whether the job is still running. The join method will return immediately in this case.

See Also:

FAQ Does the platform have support for concurrency? FAQ What is the purpose of job families? FAQ How can I track the lifecycle of jobs?


This FAQ was originally published in Official Eclipse 3.0 FAQs. Copyright 2004, Pearson Education, Inc. All rights reserved. This text is made available here under the terms of the Eclipse Public License v1.0.

Back to the top