-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nested futures that doesn't terminate #348
Comments
Are you saying it hangs when you use: future::plan(list(future::multiprocess, future::sequential)) but not future::plan(future::multiprocess) which effectively should be identical because when no more plans are specified, it'll fall back to using Also, what's you |
Using Thank you for the quick reply. Can you reproduce this?
|
Also, I think I forgot to mention that if I run do |
I got a segfault when I ran the parallelized run on a mac. (Sequential run was fine)
Mac session info
|
Hi. I haven't had time to reproduce/troubleshoot your original problem, but I'm suspect you're hitting issues because forked processes are in place (= I would switch to using |
Just to clarify, this is not specific to the future framework. So, if the fork+threading is the cause of your problem, then there is no solution to it. Instead, you need to turn to workarounds, such as launching xgboost on each worker independently of the others. Oh... and I forgot to say, set options(future.globals.onReference = "error") that will help identify cases where there're non-exportable objects in the parallelized code, cf. https://cran.r-project.org/web/packages/future/vignettes/future-4-non-exportable-objects.html |
Thank you so much for the feedback @HenrikBengtsson |
I wouldn't call it a well-known factor for me. I've only heard anecdotal from various savvy R users, but I don't have a solid example yet (at least not one I recall). I do not know for sure that A lower hanging fruit might be: options(future.globals.onReference = "error") If that's the culprit and one can find a reasonable argument for that being the problem, then it could be added to the list of common examples. (Some onReference errors are false positives because the underlying package was designed to handle lost external pointers). |
I can reproduce the "stall" on R 3.6.1 on Linux (Ubuntu 18.04): library(magrittr)
library(mlr3)
library(mlr3learners)
run_xgb <- function(dta, target_column = "Sepal.Length") {
ttsk <- mlr3::TaskRegr$new("ttsk", backend = dta, target = target_column)
learner <-
mlr3::lrn(
"regr.xgboost",
objective = "reg:linear",
eval_metric = "rmse",
nrounds = 100,
verbose = 0
)
learner$train(ttsk)
learner$predict(ttsk)$response
}
dtas_lst <-
list(
dta1 = iris %>% dplyr::select(-Species) %>% utils::head(75),
dta2 = iris %>% dplyr::select(-Species) %>% utils::tail(75)
)
future::plan("multicore", workers = 2L)
## assert all globals can be exported
options(future.globals.onReference = "error") ## just in case
y <- furrr::future_map(dtas_lst, run_xgb, .progress = TRUE)
str(y) Disabling multi-threading for xgboost using: RhpcBLASctl::omp_set_num_threads(1L) seems to fix the problem. However, for me it also works to set something less that the default eight (8) max threads. Even: RhpcBLASctl::omp_set_num_threads(7L) works for me. That confuses me. See alsoThere's a related xgboost issue over topepo/caret#1106 (comment). |
I am having issues with nested
future
calls.Here I'm using
mlr3
andfurrr
, both usingfuture
package. When using them both together I'm having issues to have the parallelized calls to terminate.I've had cases where the parallel runs do work once during a session, but then not terminating on a rerun.
Sometimes when closing down the session (after manually terminating the parallel run), I get the below message
# Error while shutting down parallel: unable to terminate some child processes
Upon googling this, I found that I could do the following check.
Does anyone have any solutions to this? Is this perhaps a bug? Related to
future
or perhapsparallel
or other package? I was having the same issue when I was running themlr
package.The text was updated successfully, but these errors were encountered: