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
# Create a specification object.specification<-Specification$new()
# Set the cluster requirements.specification$set_cores(2)
specification$set_type("psock")
# Create an asynchronous backend.backend<-AsyncBackend$new()
# Create a progress-tracking context.context<-ProgressDecorator$new()
# Create a bar.bar<-ModernBar$new()
# Set the backend.context$set_backend(backend)
# Start the backend.context$start(specification)
# Set the bar.context$set_bar(bar)
# Configure the bar.context$configure_bar(show_after=0)
# Run a task.context$sapply(1:1000, function(x) { Sys.sleep(0.01); x })
# Get the output.output<-context$get_output()
# Close the backend.context$stop()
It most likely has to do with the private method .decorate() in the ProgressDecorator class. It seems that on Unix systems, the injection
works as expected. However, on Windows, it leads to race conditions. Therefore,
the temporary log file does not contain as many new lines as the tasks that were
executed. As a result, the task finishes executing, but the progress bar is not
updated to reflect this. Then, the function hangs, waiting for the progress bar
to be terminated.
Two possible ways I can think to tackle this:
Ensure the log file is locked while a process writes to it (e.g., see filelock package). Will have to understand how much overhead this adds.
Worst-case scenario, it may only be used for Windows systems.
In the .show_progress() of the ProgressDecorator class, check the task
state and break out of the loop to update the progress bar if the task
is finished. This is not desirable, however, as it would mean that the
progress bar would not reflect the actual progress of the task.
The following code will fail on Windows.
It most likely has to do with the private method
.decorate()
in theProgressDecorator
class. It seems that on Unix systems, the injectionparabar/R/ProgressDecorator.R
Lines 153 to 161 in e0da7d9
works as expected. However, on Windows, it leads to race conditions. Therefore,
the temporary log file does not contain as many new lines as the tasks that were
executed. As a result, the task finishes executing, but the progress bar is not
updated to reflect this. Then, the function hangs, waiting for the progress bar
to be terminated.
Two possible ways I can think to tackle this:
Ensure the log file is locked while a process writes to it (e.g., see
filelock
package). Will have to understand how much overhead this adds.Worst-case scenario, it may only be used for Windows systems.
In the
.show_progress()
of theProgressDecorator
class, check the taskstate and break out of the loop to update the progress bar if the task
is finished. This is not desirable, however, as it would mean that the
progress bar would not reflect the actual progress of the task.
parabar/R/ProgressDecorator.R
Lines 192 to 207 in e0da7d9
Thanks to @eschat for uncovering this.
The text was updated successfully, but these errors were encountered: