0

I have been checking similar questions. This one is quite similar what I want to ask but not really I have the answer. Also This question I have checked.

Question that I have is that I have a SwingWorker which does long processes in the background.

    @Override
   protected final List<Object> doInBackground() throws Exception
   {
    //Should I add if(this.isCancelled) here?
    List<Object> objectList = someFecthingMethod();
    //Should I add if(this.isCancelled) here?
    objectList.forEach(object -> executor.submit(new Helper(object));

    this.latch.await();
    //Should I add if(this.isCancelled) here?
    someOtherLongRunningMethodBasedOnHelperResults();
   }

In scratch I have a code like that. This runs when calculate button of mine which triggers the worker when it is clicked. I also want to be able to cancel it. I have written needed method stop() where it has cancel() method of worker itself.

Like below in my Worker Class I have my stop method like below:

@Override
public boolean stop()
{
   return this.cancel( true );
}

When I call this method, I check in doInBackground(), this.isCancelled() returns true.. But anyway it keeps executing the methods within doInBackground(). So my question is that, should I be adding if(this.isCancelled()) check before every method in doInBackground() to stop it immediately, is there any better way to do stop it from executing when its canceled?

Thank you in advance.

Bleach
  • 309
  • 3
  • 18
  • It doesn't help if that method is already in execution when cancel event occurs. –  Nov 26 '18 at 10:11
  • @EugenCovaci I am thinking while it is executing `someFetchingMethod()` if cancelling occurs, I would expect it to keep fetching until it returns some result. Then I would expect it to stop running the rest since it is cancelled. This is my question in fact, should I be checking in every step if it is cancelled or not? – Bleach Nov 26 '18 at 10:14
  • 1
    It would be much better if you create a [mcve] instead of giving fragments of the code and then describing changes to those fragments of code. We could run it ourselves and see where you get stuck. – RealSkeptic Nov 26 '18 at 10:21
  • when you do cancel(true) it will interrupt the code. If we take a look at your worker code it won't be stopped until this.latch.await() that will throw an InteruptedException if the interruption occurred while waiting. If the interruption occurred after you should check often in someOtherLongRunningMethodBasedOnHelperResults() if the tread has been interrupted and stop the process. – JEY Nov 26 '18 at 10:22
  • @JEY So I should simply check in every step if the worker is cancelled or not? – Bleach Nov 26 '18 at 10:25
  • Yes or a more common way is to check for Thread interruption Thread.currentThread().isInterrupted(); – JEY Nov 26 '18 at 10:36

1 Answers1

0

You can create a wrapper around that provides the ability to cancel the latch. It will need to track the waiting threads and release them when they timeout as well as remember that the latch was cancelled so future calls to await will interrupt immediately.

MS90
  • 1,219
  • 1
  • 8
  • 17
  • I am not sure if I fully understood you. – Bleach Nov 26 '18 at 10:20
  • @Bleach Something like /** * Unblocks all threads waiting on this latch and cause them to receive an * AbortedException. If the latch has already counted all the way down, * this method does nothing. */ public void abort() { if( conditionMet) return; this.aborted = true; while(conditionNotMet) countDown(); } – MS90 Nov 26 '18 at 10:25