Skip to content
Snippets Groups Projects
  1. Mar 09, 2018
  2. Mar 08, 2018
  3. Mar 07, 2018
    • Carl Lerche's avatar
      Shutdown the thread pool on drop. (#190) · 5555cbc8
      Carl Lerche authored
      Currently, if a thread pool instance is dropped without being shutdown,
      the workers will run indefinitely. This is not ideal as it leaks the
      threadpool.
      
      This patch forces the thread pool to shutdown on drop.
      
      Closes #151
  4. Mar 06, 2018
  5. Mar 05, 2018
  6. Mar 04, 2018
  7. Mar 02, 2018
  8. Feb 28, 2018
    • Carl Lerche's avatar
      Update the README (#164) · 164ee8f1
      Carl Lerche authored
    • Carl Lerche's avatar
      Update AppVeyor badge URL (#163) · 7238cfa5
      Carl Lerche authored
    • Carl Lerche's avatar
      Provide a handle to Runtime's executor. (#162) · 7de749b7
      Carl Lerche authored
      Sometimes, passing ownership to an executor is necessary. For example,
      some libraries require taking ownership of one.
      
      This patch adds a function that returns an executor associated with a
      runtime.
    • Carl Lerche's avatar
      I/O resources lazily bind to reactor. (#160) · 2eabc375
      Carl Lerche authored
      This patch makes a significant change to how I/O resources bind to a
      reactor. Currently, an I/O resource (TCP, UDP, PollEvented) will bind
      itself with a reactor upon creation.
      
      First, some history.
      
      Originally, tokio-core required that I/O resources be explicitly
      associated with a reactor upon creation by passing in a `&Handle`. Tokio
      reform introduced a default reactor. If I/O resources do not specify a
      reactor upon creation, then the default reactor is used.
      
      However, futures tend to favor being lazy. Creating a future should do
      no work, instead it is defining a computation to be performed once the
      future is executed. Binding an I/O resource with a reactor on creation
      goes against this pattern.
      
      This patch fixes this by allowing I/O resources to lazily bind to a
      reactor. An explicit `&Handle` can still be used on creation, but if no
      reactor is specified, then the default reactor is used. However, this
      binding happens during execution time (read / write) and not creation.
    • Roman's avatar
      Improve current thread tests (#161) · 1190176b
      Roman authored
      * Create variables as closer as possible to their usage
      * Check that no message is lost in test current_thread::hammer_turn
      1190176b
  9. Feb 27, 2018
    • Carl Lerche's avatar
      Support current_thread::spawn from task drop (#157) · 8e1a9101
      Carl Lerche authored
      Currently, the thread-local tracking the current thread executor is not
      set when a task is dropped. This means that one cannot spawn a new
      future from within the drop implementation of another future.
      
      This patch adds support for this by setting the thread-local before
      releasing a task.
      
      This implementation is a bit messy. It probably could be cleaned up, but
      this is being put off in favor of trying a more comprehensive
      reorganization once the current thread executor is feature complete.
    • Roman's avatar
      Update badges in README (#159) · 427b7325
      Roman authored
      427b7325
    • Carl Lerche's avatar
      Fix race condition in CurrentThread. (#156) · 2961a238
      Carl Lerche authored
      The logic that enables `CurrentThread::turn` to avoid unbounded
      iteration was incorrect. It was possible for unfortunate timing to
      result in a dead lock.
      
      This patch provides a fix as well as a test.
  10. Feb 26, 2018
  11. Feb 24, 2018
    • Carl Lerche's avatar
      Fix bug with CurrentThread::turn (#152) · 5334de5e
      Carl Lerche authored
      CurrentThread::turn uses a turn count strategy to allow `turn` to not
      run infinitely. Currently, there is a bug where spawned tasks will not
      get executed in calls to `turn`.
      
      This patch fixes the bug by correctly setting the turn count for newly
      spawned tasks.
  12. Feb 21, 2018
    • Carl Lerche's avatar
      Introduce the Tokio runtime: Reactor + Threadpool (#141) · fe14e7b1
      Carl Lerche authored
      This patch is an intial implementation of the Tokio runtime. The Tokio
      runtime provides an out of the box configuration for running I/O heavy
      asynchronous applications.
      
      As of now, the Tokio runtime is a combination of a work-stealing thread
      pool as well as a background reactor to drive I/O resources.
      
      This patch also includes tokio-executor, a hopefully short lived crate
      that is based on the futures 0.2 executor RFC.
      
      * Implement `Park` for `Reactor`
      
      This enables the reactor to be used as the thread parker for executors.
      This also adds an `Error` component to `Park`. With this change, a
      `Reactor` and a `CurrentThread` can be combined to achieve the
      capabilities of tokio-core.
  13. Feb 20, 2018
  14. Feb 14, 2018
  15. Feb 13, 2018