@async cancellation/interrupt options

[zekronium]

Hi,

I see you also have a tbd on interrupt/cancellation features.

I tried searching the repo and examples but the only feature I find is .cancel(bool) on the Future itself.

Is there a way to implicitly interrupt an awaiting method (think of interrupting a blocking method with Thread.interrupt()).

The only way I see it right now, to have cancellation support you must save the future and make it visible by an other method to cancel it, effectively requiring you to always have a future variable dedicated.

Is there another feature that allows to "find" an awaiting future contextually, maybe per object instance as context scope, effectively mimicking thread interrupts but in this case on the "continuation" context

Thank you

[vsilaev]

Hi! TBD is for docs only, the functionality itself is implemented.

1. You always can use Future.cancel(true) on the CompletableFuture / Promise / CompletionStage (with the upcast to the Future) returned -- this will cancel the future.
2. The internal code might be interrupted, it depends on the following conditions:

• You are using interruptible scheduler
• Underlying Executor of the scheduler is interruptible (ThreadPoolExecutor is interruptible, but ForkJoinPool is not!)
• Your method is either at waiting state (like Object.wait, Thread.sleep, CompletableFuture.join) or at the AsyncCall.await state (awaiting other future) or is awaiting for the NIO.
• Alternatively, you blocking IO is warped into BlockingIO.register block, please see https://github.com/vsilaev/tascalate-concurrent
• If you code is computational-bound rather than IO-bound you can use AsyncCall.interrupted to check for interruptions and either exit early or throw an exception (cooperative interruptions)

[zekronium]

Have you ever tested how this behaves on NIO eventloop environments, technically the method/thread/object is never blocked since its monitoring the Selector for IO, so I assume this would fall under the AsyncCall.await “wait” state in this case.

When the future itself is cancelled, but in situations where eventloops are used, most of opperations are wrapped in runnables for scheduling, I assume in such environments the excution itself might not be cancelled but just the result then (since Future would be cancelled).

Maybe theres a possibility to implement my own scheduler to cancel the execution more appropriately.

I am using netty to be exact

[vsilaev]

Selector.select() should be interrupted in this case, no? Can you create a minimal test app that demonstrates the issue?

[zekronium]

Its not entirely an issue, atleast I dont know if it is.

Hence why I asked your opinion on how do you think it might behave and if there might be side-affects.

I also considered maybe re-implementing the Scheduler so it could better facilitate use of eventloops if you think that would be necessary.

From my tests, tascalate takes the from context direct scheduler, which is not marked as interruptible. Thats why I was considerate of how is the cancellation logic handled in that case, I assume the "asynctask" is wrapped in some sort of a state holder that simply prevents the codeblock from being executed? Since I saw the generated code also wraps things in classes extending Runnable

[vsilaev]

I need some real code to comment. Try to do the most straightforward thing:

1. use annotated with @SchedulerProvider async method parameter of type Scheduler
2. for Scheduler use interruptible version with interruptible executor like this:

       ExecutorService myExecutor = Executors.newFixedThreadPool(4);
       Scheduler myScheduler = Scheduler.interruptible(myExecutor);

[vsilaev]

Closing issue as far as no follow-up from the issue opener