1. 23 Sep, 2022 1 commit
  2. 22 Sep, 2022 3 commits
  3. 21 Sep, 2022 5 commits
  4. 19 Sep, 2022 2 commits
    • Mart Raudsepp's avatar
      dav1ddec: Require dav1d 1.0.0 in meson · 4928a2ba
      Mart Raudsepp authored and Arun Raghavan's avatar Arun Raghavan committed
      !698
      raised the dependency via bumping the dav1d rust crate used, but didn't add
      a requirement at meson level, thus with automatic or enabled option for dav1d
      it would pass with an older failure, but then during compilation phase fail
      with:
      
        --- stderr
        thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: PkgConfig(`"pkg-config" "--libs" "--cflags" "dav1d" "dav1d >= 1.0.0"` did not exit successfully: exit status: 1
        error: could not find system library 'dav1d' required by the 'dav1d-sys' crate
      
        --- stderr
        Package dependency requirement 'dav1d >= 1.0.0' could not be satisfied.
        Package 'dav1d' has version '0.8.2', required version is '>= 1.0.0'
        )', /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/dav1d-sys-0.5.0/build.rs:80:10
        note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
      warning: build failed, waiting for other jobs to fini...
      4928a2ba
    • Thibault Saunier's avatar
      meson: Use workspace Cargo.toml to find crates path · f19af9f7
      Thibault Saunier authored and Sebastian Dröge's avatar Sebastian Dröge committed
      We were globing recursively during meson run and it was spending 20secs
      here in total only to run the dependencies.py script
      f19af9f7
  5. 17 Sep, 2022 2 commits
  6. 16 Sep, 2022 6 commits
  7. 15 Sep, 2022 3 commits
  8. 14 Sep, 2022 1 commit
  9. 13 Sep, 2022 9 commits
    • rajneeshksoni's avatar
      s3sink, s3src: Max 1 (re)try when retry-duration < request_timeout. · 45962eca
      rajneeshksoni authored and Sebastian Dröge's avatar Sebastian Dröge committed
      When retry-duration is less than request_timeout, only 1 try
      is attempted.
      45962eca
    • rajneeshksoni's avatar
      s3sink: Dont set call_timeout,call_attempt_timeout is enough with retry. · 62f76e1e
      rajneeshksoni authored and Sebastian Dröge's avatar Sebastian Dröge committed
      When call_timeout is triggered, request will fail
      irrespective of the retry setting. call_timeout define
      max time request can take along with retry.
      It can be solved by either setting call_timeout to
      retry * call_attempt_timeout or not setting the call_timeout.
      
      As per thread call_attempt and rety setting is enough.
      https://github.com/awslabs/aws-sdk-rust/issues/558
      62f76e1e
    • François Laignel's avatar
      ts/scheduler: fix shutdown · 1be30b8e
      François Laignel authored and Sebastian Dröge's avatar Sebastian Dröge committed
      A strong handle reference was held in the `block_on_priv` `Result`
      handler in the thread for the `Scheduler::start` code path, which
      lead to the `Handler` strong count not dropping to 0 when it
      should, leading to the shutdown request not being triggered.
      
      Use an Arc<AtomicBool> instead of a oneshot channel for shutdown.
      The main Future is always polled and never relies on a waker, a
      `poll_fn` is cheap and does the job.
      
      Unpark the scheduler after posting a request to shutdown.
      1be30b8e
    • François Laignel's avatar
      ts/scheduler: improve tasks / io & timers polling balance · ab327be9
      François Laignel authored and Sebastian Dröge's avatar Sebastian Dröge committed
      Set a limit to the nb of task checked before checking the reactor
      and the main future again.
      ab327be9
    • François Laignel's avatar
      ts/Task: don't drain sub tasks after state transition and iteration · d39aabe0
      François Laignel authored and Sebastian Dröge's avatar Sebastian Dröge committed
      Subtasks are used when current async processing needs to execute
      a `Future` via a sync function (eg. a call to a C function).
      In this case `Context::block_on` would block the whole `Context`,
      leading to a deadlock.
      
      The main use case for this is the `Pad{Src,Sink}` functions:
      when we `PadSrc::push` and the peer pad is a `PadSink`, we want
      `PadSrc::push` to complete after the async function on the
      `PadSink` completes. In this case the `PadSink` async function
      is added as a subtask of current scheduler task and
      `PadSrc::push` only returns when the subtask is executed.
      
      In `runtime::Task` (`Task` here is the execution Task with a
      state machine, not a scheduler task), we used to spawn state
      transition actions and iteration loop (leading to a new
      scheduler Task). At the time, it seemed convenient for the user
      to automatically drain sub tasks after a state transition action
      or an iteration. User wouldn't have to worry about this, similarly
      to the `Pad{Src,Sink}` case.
      
      In current implementation, the `Task` state machine now operates
      directly on the target `Context`. State transtions actions and
      the iteration loop are no longer spawned. It seems now useless to
      abstract the subtasks draining from the user. Either they
      transitively use a mechanism such as `Pad{Src,Sink}` which already
      handles this automatically, or they add substasks on purpose, in
      which case they know better when subtasks must be drained.
      d39aabe0
    • François Laignel's avatar
      ts/executor: clear the reactor instead of closing it... · af12bce1
      François Laignel authored and Sebastian Dröge's avatar Sebastian Dröge committed
      ... so that it can be reused on current thread for subsequent
      Scheduler instantiations (e.g. block_on) without the need to
      reallocate internal data structures.
      af12bce1
    • François Laignel's avatar
      ts/timers: multiple improvements · 61c62ee1
      François Laignel authored and Sebastian Dröge's avatar Sebastian Dröge committed
      This commit improves threadshare timers predictability
      by better making use of current time slice.
      
      Added a dedicate timer BTreeMap for after timers (those
      that are guaranteed to fire no sooner than the expected
      instant) so as to avoid previous workaround which added
      half the max throttling duration. These timers can now
      be checked against the reactor processing instant.
      
      Oneshot timers only need to be polled as `Future`s when
      intervals are `Stream`s. This also reduces the size for
      oneshot timers and make user call `next` on intervals.
      Intervals can also implement `FusedStream`, which can help
      when used in features such as `select!`.
      
      Also drop the `time` module, which was kepts for
      compatibility when the `executor` was migrated from tokio
      based to smol-like.
      61c62ee1
    • François Laignel's avatar
      ts: add feature to add counters for performance evaluation · 235ded35
      François Laignel authored and Sebastian Dröge's avatar Sebastian Dröge committed
      Add a `tuning` feature which adds counters that help with performance
      evaluation. The only counter added so far accumulates the duration a
      Scheduler has been parked, which is pretty accurate an indication of
      CPU usage of the Scheduler.
      235ded35
    • François Laignel's avatar
      ts/standalone: multiple improvements · 72acbebf
      François Laignel authored and Sebastian Dröge's avatar Sebastian Dröge committed
      - Reworked buffer push.
      - Reworked stats.
      - Make first elements logs stand out. This make it possible to
        follow what's going on with pipelines containing 1000s of
        elements.
      - Actually handle EOS.
      - Use more significant defaults.
      - Allow building without `clap` feature.
      72acbebf
  10. 12 Sep, 2022 8 commits