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
It looks like the cache created by ExperimentHub is not parallel-safe, i.e. if you run multiple R processes, or R sessions concurrently, you might end up with:
When I run reverse dependency checks on matrixStats, I experience the above with high probability. I use revdepcheck for this. It works by running two concurrent sessions of R CMD check on each package tested. One of the checks ("old") is with the CRAN version of matrixStats and the other ("new") is with the development version of matrixStats. Then revdepcheck compares the result of these two to see if there's any negative impact from the developer's version of matrixStats.
Thus, when running this in parallel, the "old" and the "new" are likely to use the same ExperimentHub cache at the same time. When that happens, there is a great risk of getting the above error. Note that this is also relevant for anyone running a parallel analyses/tasks that all use ExperimentHub.
To give further evidence that this is a race-condition problem, the problem is 100% avoided if I check the reverse-dependency packages sequentially so that "old" and "new" runs are not run at the same time. You can see the difference that running in parallel and sequentially makes in HenrikBengtsson/matrixStats@0cb249b.
The text was updated successfully, but these errors were encountered:
Issue
It looks like the cache created by ExperimentHub is not parallel-safe, i.e. if you run multiple R processes, or R sessions concurrently, you might end up with:
Details
When I run reverse dependency checks on matrixStats, I experience the above with high probability. I use revdepcheck for this. It works by running two concurrent sessions of
R CMD check
on each package tested. One of the checks ("old") is with the CRAN version of matrixStats and the other ("new") is with the development version of matrixStats. Then revdepcheck compares the result of these two to see if there's any negative impact from the developer's version of matrixStats.Thus, when running this in parallel, the "old" and the "new" are likely to use the same ExperimentHub cache at the same time. When that happens, there is a great risk of getting the above error. Note that this is also relevant for anyone running a parallel analyses/tasks that all use ExperimentHub.
To give further evidence that this is a race-condition problem, the problem is 100% avoided if I check the reverse-dependency packages sequentially so that "old" and "new" runs are not run at the same time. You can see the difference that running in parallel and sequentially makes in HenrikBengtsson/matrixStats@0cb249b.
The text was updated successfully, but these errors were encountered: