Thanks to visit codestin.com
Credit goes to github.com

Skip to content

DESIGN: Pros and cons of different solutions #3

@HenrikBengtsson

Description

@HenrikBengtsson

Progress updates via '.progress' argument

Example:

y <- future_lapply(..., .progress = function(...) { ... })

Pros:

  • Clear that function produces progress info

Cons:

  • Requires specifying progress argument
  • It is not possible to listen to progress info from nested "internal" functions

Progress updates via centralized "progress" subscription

Example:

progress_subscribe(function(name, step, ...) {
  # called each time there is a progress update
})

y <- future_lapply(...)

Pros:

  • Anyone can subscribe
  • No "progress" argument

Cons:

  • Not clear how to handled nested progress updated
  • Not clear who can/should subscribe

Progress updates via condition signaling

Example:

progress_relay({
  y <- future_lapply(...)
})

Pros:

  • Anyone can listen from anywhere upstream
  • No "progress" argument
  • No need to update code when a downstream function introduces progress info (correct?)
  • Progress conditions can be captured, filtered, summarized locally in functions and then resignaled in different forms and shapes.

Cons:

  • Requires wrapping whole expressions, e.g. relay_progress(y <- foo())
  • End user needs to wrap calls to, but we might be able to use a task callback handler to handle progress conditions that bubble up to the top level.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions