Unless the current thread is interrupting itself, which is always permitted
You may want to play around those thread methods wait, notify, sleep etc to see what happens.
Can you stab yourself when you are coma? No!
Would it be reasonable to assume that any thread that is in its run method and is executing some piece of code there has its interrupted bit set to false( the first time at least)
Only when it is interrupted ( for now let us assume by other threads ), its interrupted bit is set.
It then throws an InterruptedException.
So is the interrupted bit reset again by default so the next time the thread checks it or if is blocked or is sleeping, it can be interrupted again?
Or would it be correct that the job of the interrupt() method is to only set the interrupted bit from false to true and from false to true only?
shouldn't we assume that the call to heavy calculation stuff is already complete. Isn't that precisely why it would reach that check?
Or let us say that the thread got interrupted somehow while performing those heavy duty calculations, wouldn't it then throw an Interrupted exception by default.
So doesn't it mean the heavy duty calls are not designed to throw an interrupted exception?
The runAll method is also not interrupting the thread it is creating. It is only interrupting itself.
I see you changed a very important line . In your example there is no much reason to keep an interrupted flag because thread is terminated shortly after a method execution. In my example there is a reason. Let's assume, that runAll has my implementation and main has your implementation. Let's assume, that a thread was interrupted during a 50000 iteration (for i loop) of a first job. At this point this job will terminate and will reset interrupted flag to "true". One level above, in a BulkRunner.runAll we will also check "inetrrupted" flag and will discard remaining two jobs. If Job.run will not set interrupted flag back to true, then two other jobs will be run. So, we will get 250000 iterations instead of 50000.
I feel this sort of interrupt combinations are more like conditionals
But then I thought - aren't there better ways of achieving that.
It made at least some sense to me in a multi-threaded case where I had multiple threads since these threads are involved in heavy duty calculations. Since these threads aren't invoking any blocking methods that can respond to interruptions, they could have these Thread.interrupted() checks followed by self interruptions constantly to give fair amount CPU to the other threads ( return or no return regardless ).