Determine if calling future({}) will block

[avsdev-cw]

In relation to issues #86 and #109 I believe it would be beneficial to have some mechanism of detecting if calling future({}) (or value(f) on a lazy future) would block.

This would provide a number of options of high level ways of building schedulers which wouldn't rely on the developer having to deal with number of cores/cluster size/etc to manage the queue.

Apologies if this already exists, but I didn't see anything documented/mentioned in the issues

[HenrikBengtsson]

Sorry for the delay. No, correct, such a feature does not exist in the Future API. It's an interesting idea. I wonder though exactly what type of questions can be asked and what answers can be guaranteed. For simplicity, imagine we create a lazy future:

f <- future(42, lazy = TRUE)

then what would:

res <- will_it_block(f)

mean for different types of backends? We know that for a sequential future the answer is TRUE and probably the same for a multicore future where not all cores are occupied. But, if you use a future.batchtools on top of a HPC scheduler with "infinite" number of workers, what should be returned? Launching such a future will not block - it will just end up on the HPC queue but it won't really start processing until later at an unknown time (when the scheduler finds an available resource). From the perspective of the Future API and usage of it, does it even matter when the future starts? What does it even mean to wait in the queue of a scheduler - all jobs sits in the queue for some time, may it be 0.01s for some jobs and 2 hours for others. All that should matter is when it completes - or not even that - just that it returns a value - blocking or not.

Maybe the answer to your question is that the Future API is not meant to be used for implementing job schedulers.

I don't know the answer to all this and I need to digest the idea much further before coming to a conclusion. But I'm open to further discussions/thoughts.

[avsdev-cw]

You are pretty close to the way I imagined it. However, my thoughts of "will_it_block()" is more about whether or not it would block the process flow of the calling R script.

For example on a dual core machine running

plan(multicore)

# Futures with random sleeps to emulate long running tasks of different lengths
f1 <- future({Sys.sleep(sample(10:360, 1)); return(42)})
f2 <- future({Sys.sleep(sample(10:360, 1)); return(42)})
f3 <- future({Sys.sleep(sample(10:360, 1)); return(42)})

f3 would block until f1 or f2 finishes.

For building a simple scheduler I would want to know that calling f3 would block and therefore would either:

• make f3 a lazy future and queue it to run later when I know f1 and/or f2 are finished;
• store the task f3 is going to perform some other way to be created as a future when f1 or f2 finishes;
• (worst case) return to the user to say that the system is already busy.

In my use case the view is: "I don't care when the future starts, I just want to queue it and I will wait for a complete signal/poll to check if it has finished at a later time, until then I need to go and do something else first, (eg tell the user the jobs are queued)"

Obviously there still needs to be a check at a programmer level that understands whether queues are sensible (multicore, multisession, HPC scheduler etc) or are not (single core, sequential) and to deal with those 2 cases, which they have to understand already.

[HenrikBengtsson]

Obviously there still needs to be a check at a programmer level that understands whether queues are sensible (multicore, multisession, HPC scheduler etc) or are not (single core, sequential) and to deal with those 2 cases, which they have to understand already.

Related to this point, it might be that will_it_block() have to return NA when neither TRUE nor FALSE can be guaranteed by the backend.

PS. Note that, I (=my extremely conservative inner self) am still trying distill/identify exactly what the core Future API is () and I'm extremely careful in adding a new "feature" before it is well understood what that entails. One of the objectives of the Core Future API is that it should handle all use cases and be supported by all backends (existing and future ones). Other features need to be "optional" since they cannot be supported everywhere - those will have to be part of the Extended/Optional Future API. This is what Issue #172 is about. It might be that will_it_block() fits in the Core API, but not sure.

[HenrikBengtsson]

Forgot to say, you might have "blocking" dependencies due to communication, e.g. launching a future on a remote system may block "for a substantial period of time" due to a poor internet connection - so what does it mean that launching future will "block"?

[schloerke]

Would about a method that answers the question "is there an idle worker?" or "will this block my main R session"?

This could remove my hacky logic that future could provide generally. Ex: if (worker_is_available()) { launch_future(f) } else { try_again_later() }. Specifically: rstudio/promises#60

---

Currently, I am accessing the number of possible workers using the code below... which does not seem robust.

workers <- formals(future::plan("next"))$workers %||% parallelly::availableCores()

Is there a cleaner way to access how many workers are executing?

# my current / hacky solution...
worker_is_available <- function() { 
  workers <- formals(future::plan("next"))$workers %||% parallelly::availableCores()

  # reach into the named `db` list and get the last entry
  reg <- tail(names(get("db", envir = environment(FutureRegistry))), 1)
  # As the registry for all workers
  used <- length(FutureRegistry(reg, action = "list", earlySignal = FALSE))

  used < workers
}

---

My take on ...

But, if you use a future.batchtools on top of a HPC scheduler with "infinite" number of workers, what should be returned? Launching such a future will not block - it will just end up on the HPC queue

This situation should always return FALSE. Adding another future here will never block the main R process.

[HenrikBengtsson]

... formals(future::plan("next"))$workers ...

Unfortunately, this won't work if workers is a function, e.g.

plan(multisession, workers = function(...) sample(2:4, size=1))

Instead, just use:

> nbrOfWorkers()
[1] 3

Which leads to ...

Would about a method that answers the question "is there an idle worker?" or "will this block my main R session"?

Maybe a first step toward this is to extend nbrOfWorkers() so that we can do:

> nbrOfWorkers(free = TRUE)
[1] 2

Maybe that will be sufficient to get going here? Since the Future API is not really aware of the concept "worker", I'm not a big fan of having to program with such a function but we might come with a wrapper function in the future that does not mention "worker" but that can come later. Anyway, I'll try to explore if it possible to support nbrOfWorkers(free = TRUE) for all future backends.

I suspect that for plan(sequential), we should always get:

> nbrOfWorkers(free = TRUE)
[1] 0

[schloerke]

Instead, just use:

> nbrOfWorkers()
[1] 3

Great! (Sorry I missed the function 🤦 )

Would about a method that answers the question "is there an idle worker?" or "will this block my main R session"?

Maybe a first step toward this is to extend nbrOfWorkers() so that we can do:

> nbrOfWorkers(free = TRUE)
[1] 2

This should work for me! In my situation, I could just check if nbrOfWorkers(free = TRUE) > 0 to know if I should schedule another future object.

Anyway, I'll try to explore if it possible to support nbrOfWorkers(free = TRUE) for all future backends.

Thank you!

I suspect that for plan(sequential), we should always get:

> nbrOfWorkers(free = TRUE)
[1] 0

Hmmmm. I'm wondering if it should always return 1. If we are able to ask the question nbrOfWorkers(free = TRUE) with plan(sequential), then at the time of executing the function, no futures would be calculating on the main R session, meaning a single worker is free.

[HenrikBengtsson]

I've just pushed branch feature/nbrOfWorkers-free with a prototype for nbrOfWorkers(free = TRUE).

I suspect that for plan(sequential), we should always get:

> nbrOfWorkers(free = TRUE)
[1] 0

Hmmmm. I'm wondering if it should always return 1. If we are able to ask the question nbrOfWorkers(free = TRUE) with plan(sequential), then at the time of executing the function, no futures would be calculating on the main R session, meaning a single worker is free.

Yes, that might be better. In the NEWS draft, I wrote:

• Add support nbrOfWorkers(free = TRUE) to query how many workers are free to take on futures immediately. ...

So, I've just pushed an update where nbrOfWorkers() always returns 1L for sequential backends regardless of free.

I think the above is an example of why the "will-it-block" feature request is tricky. It probably depends on what you're after and why you're asking the question. I don't remember all the details, but we had discussions in the past on "asynchronousness" and whether that should be something one should be able to request/declare. I've got too little time and am too tired to revisit that right now, but it could be related to the use-cases here.