You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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):
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.
The text was updated successfully, but these errors were encountered:
Unit: milliseconds
expr min lq mean median uq max neval cld
callr 145.128327 154.612408 165.7934 162.1669 176.778607 220.87554 100 b
mcp 4.037625 5.281864 6.0387 5.7238 6.357726 10.86342 100 a
Unit: milliseconds
expr min lq mean median uq max neval cld
r 145.869876 153.497698 161.952199 158.633111 168.728134 222.200421 100 c
rs 17.170834 21.156948 24.776113 24.541950 28.002778 35.160594 100 b
mcp 1.980955 2.721543 2.998776 2.998492 3.285335 4.583885 100 a
forkTimeout()
usesparallel::mcparallel()
to impose a hard time limit on a function call. Unfortunately, this mechanism is not available on Windows. In all evidence, thecallr
package 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.The text was updated successfully, but these errors were encountered: