forkTimeout() uses parallel::mcparallel() to impose a hard time limit on a function call. Unfortunately, this mechanism is not available on Windows. In all evidence, the callr package does not have this limitation. It may be worthwhile to switch forkTimeout() to use it instead, assuming it does not impose too much of a speed penalty (and even if it does, use it on Windows only).
Background
From statnet/ergm-private#230, certain inputs can reliably hang ergm::is.inCH() via lpSolve::lp(), sending it into an infinite loop (or something indistinguishable from one):
library(lpSolve)
load(unz("lp_input.zip","lp_input.RData"))
lp(objective.in = c(-q, q),
const.mat = rbind( c(q, -q), cbind(L, -L)),
const.dir = "<=",
const.rhs = c(1, rep(0, NROW(L)))
)Commits c2210ba and statnet/ergm@c417215 mostly neutralise this problem on Unix-alikes forkTimeout() to terminate the call if it takes too long and rerun with invariantly perturbed input, which seems to always fix the problem.
forkTimeout()usesparallel::mcparallel()to impose a hard time limit on a function call. Unfortunately, this mechanism is not available on Windows. In all evidence, thecallrpackage does not have this limitation. It may be worthwhile to switchforkTimeout()to use it instead, assuming it does not impose too much of a speed penalty (and even if it does, use it on Windows only).Background
From statnet/ergm-private#230, certain inputs can reliably hang
ergm::is.inCH()vialpSolve::lp(), sending it into an infinite loop (or something indistinguishable from one):Commits c2210ba and statnet/ergm@c417215 mostly neutralise this problem on Unix-alikes
forkTimeout()to terminate the call if it takes too long and rerun with invariantly perturbed input, which seems to always fix the problem.