1. 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
  2. 12 Sep, 2022 9 commits
  3. 10 Sep, 2022 1 commit
    • Jordan Petridіs's avatar
      ci/windows: Build all the crates at once · 165f3a78
      Jordan Petridіs authored
      In gst-rs we build each crate on its own, since not all
      crates share the same features and some conflict with each other.
      
      However currently, that isn't the case in plugins-rs and instead
      we can be building all the crates with the same flags and simplify
      the the script.
      
      Close #241
      165f3a78
  4. 09 Sep, 2022 4 commits
  5. 08 Sep, 2022 2 commits
  6. 07 Sep, 2022 1 commit
  7. 06 Sep, 2022 2 commits
  8. 05 Sep, 2022 6 commits
  9. 04 Sep, 2022 2 commits
  10. 03 Sep, 2022 2 commits
  11. 02 Sep, 2022 2 commits