king-of-poppk

Maybe an easier first attempt is to simply drop in the following (or the C equivalent) at the very beginning of the worker: ```R interruptCount

I just tried ```R future::plan( future::multisession, rscript_startup = "globalCallingHandlers(interrupt = \\(.) .tryResumeInterrupt())" ) ``` and ~it does make things more robust, although not perfect.~ **PS**: Upon further inspection, it does...

> Note that `Sys.sleep()` cannot be interrupted, e.g. [#29 (comment)](https://github.com/HenrikBengtsson/parallelly/issues/29#issuecomment-716212988) OK. I am on MacOS Ventura 13.5 with R4.2 and I witness the following which seems contradictory: ```r y

> My gut feeling says that one cannot assume a calling handler can handle the case when there is a burst of interrupts coming in. Indeed: ```r globalCallingHandlers( interrupt =...

> AFAIK, `suspendInterrupts()` should handle such cases. Here is what I tried, without success: ```r future::plan( future::multisession, rscript_args = c( "*", "-e", shQuote( "suspendInterrupts(parallel:::.workRSOCK())", type = "sh" ) ) )...

> For instance, what happens if there is another interrupt signalled when we're in the middle I understand this can happen in general, however, I was hoping that this would...

Would it make sense to start `callr::r_session`'s in the background so that at least we do not have to wait for process startup after an idleness period? Maybe `workers` would...