tascalate-async-await
tascalate-async-await copied to clipboard
@async cancellation/interrupt options
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
Hi! TBD is for docs only, the functionality itself is implemented.
- You always can use
Future.cancel(true)
on theCompletableFuture
/Promise
/CompletionStage
(with the upcast to theFuture
) returned -- this will cancel the future. - 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 theAsyncCall.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)
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
Selector.select() should be interrupted in this case, no? Can you create a minimal test app that demonstrates the issue?
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
I need some real code to comment. Try to do the most straightforward thing:
- use annotated with @SchedulerProvider async method parameter of type Scheduler
- for Scheduler use interruptible version with interruptible executor like this:
ExecutorService myExecutor = Executors.newFixedThreadPool(4);
Scheduler myScheduler = Scheduler.interruptible(myExecutor);
Closing issue as far as no follow-up from the issue opener