king-of-poppk

What is the purpose of this `input$` feedback on updates triggered from the server? Is it because input changes could come from client-side logic? Is there a way to opt-out?...

The suggestion of @dansmith01 somewhat works: eventually no nodes are left and `future::future` hangs, which is not so cool. When I try what you suggest @HenrikBengtsson, I get the following...

@HenrikBengtsson Here are some intereseting minimal "non-working" examples: Without sleep: ``` > future::plan(future::multisession, workers = 2) > f tools::pskill(f$workers[[f$node]]$session_info$process$pid, signal = tools::SIGINT) > future::value(f) Error in unserialize(node$con) : MultisessionFuture ()...

**PS**: OK, `workers = 1` is a bit of an edge case since it just falls back to sequential/lazy.

This one seems like a step in the right direction: ``` > future::plan(future::multisession, workers = 2); > f later::later(\() {tools::pskill(f$workers[[f$node]]$session_info$process$pid, signal = tools::SIGINT); print(future::value(f))}) later: exception occurred while executing callback:...

In a real-world scenario, I still manage to make it crash with `later`. Is it possible that https://github.com/HenrikBengtsson/future/issues/438 is what I am looking after?

Note that using `future.callr` as the backend makes it really easy reliably interrupt futures. You can even suspend and resume them. It's true that other backends would require a more...

Continuing on https://github.com/HenrikBengtsson/future/issues/93#issuecomment-1655523337: it may actually be that the cause of the error is much simpler. If I try to get the job node before calling `future::value` I run into...

This is the last obstacle for me to implement efficient cancellable promises and truly asynchronous Shiny reactives on top of `future`. I currently resorted to not interrupting cancelled futures, but...

**PS**: I replaced my homemade `later`/`callr::r_bg` implementation with `future.callr`. Much simpler, but still as slow.