Register that workers are expected. This generates a key that one
or more workers will write to when they start up (as used by
rrq_worker_spawn).
rrq_worker_expect(obj, worker_ids)
rrq_worker_expect2(worker_ids, controller = NULL)
rrq_worker_wait(obj, key_alive, timeout = Inf, poll = 1, progress = NULL)
rrq_worker_wait2(
key_alive,
timeout = Inf,
poll = 1,
progress = NULL,
controller = NULL
)A rrq_controller object
Ids of expected workers
The controller to use. If not given (or NULL)
we'll use the controller registered with
rrq_default_controller_set().
A key as returned by rrq_worker_expect
Number of seconds to wait for workers to appear. If they have not appeared by this time, we throw an error.
Poll interval, in seconds. Must be an integer
Optional logical indicating if a progress bar
should be displayed. If NULL we fall back on the value of the
global option rrq.progress, and if that is unset display a
progress bar if in an interactive session.
For rrq_worker_expect: A string, which can be passed through
as the second argument to rrq_worker_wait in order to block
until workers are available.
For rrq_worker_wait: Invisibly a difftime object with the time
spent waiting.
The general pattern here is that the process that submits the
worker (so the parent process, or the user submitting a cluster
job) would run this function to register that some number of
workers will be started at some point in the future. In the case
of starting workers by submitting them to a cluster, this could
take a long time as the job queues, or if starting by running
another process it could be very quick. Information about the
workers that are expected and where to find them is stored against
a key, which is returned by rrq_worker_expect.
Then, to wait on a set of workers, you run rrq_worker_wait