1. 24 Dec, 2018 2 commits
  2. 05 Jan, 2018 1 commit
  3. 13 Sep, 2017 1 commit
    • Alex Crichton's avatar
      Ensure errors on TCP writes happen on Windows (#725) · 5b9d20c4
      Alex Crichton authored
      Previously an error in a TCP write might accidentally get covered up as the
      `write` function didn't check for `State::Error`. This updates that logic to
      propagate the error out to ensure if we see an error it goes upwards.
      5b9d20c4
  4. 05 Sep, 2017 1 commit
  5. 20 Aug, 2017 1 commit
  6. 28 Jul, 2017 1 commit
  7. 26 Apr, 2017 1 commit
  8. 10 Mar, 2017 2 commits
  9. 23 Feb, 2017 1 commit
  10. 22 Feb, 2017 1 commit
  11. 14 Feb, 2017 1 commit
    • Carl Lerche's avatar
      Rewrite the readiness queue · 43a69f21
      Carl Lerche authored
      The current readiness queue implication has some concurrency bugs. So,
      instead of fixing the bug, let's rewrite everything! :)
      
      But more seriously, the current implication has some problems (besides
      having bugs):
      
      * It's complicated
      * It is not fair when using level-triggered notifications
      * It is !Sync
      
      This implication will hopefully resolve the bugs, as well as simplifying
      the implementation by reducing all the critical concurrent state for a
      given node to a single atomic variable. It also changes the queueing
      strategy from a stack to an actual queue based on the 1024cores MPSC
      queue. However, this queue is able to reuse the nodes.
      
      The last step in making `Poll` fully `Sync` is to coordinate calls to
      `poll`. There can only be one single concurrent call to `poll`.
      
      In order to respect the timeout argument to `poll`, Mutex cannot be used
      for coordination. This is due to the lack of a `lock_timeout` function.
      Instead, we use a combination of an atomic, a mutex, and a condvar. The
      atomic enables a fast path when `Poll` is used on a single thread. In
      the event of concurrent calls to `poll`, extra threads block using the
      condvar until they are granted access.
      43a69f21
  12. 09 Feb, 2017 1 commit
  13. 22 Jan, 2017 1 commit
  14. 20 Jan, 2017 1 commit
  15. 14 Dec, 2016 1 commit
    • Alex Crichton's avatar
      Allow registration of custom handles on Windows · ac8b7de4
      Alex Crichton authored
      This commit intends to extend the functionality of mio on Windows to support
      custom handles being registered with the internal IOCP object. This in turn
      should unlock the ability to work with named pipes, filesystem changes, or any
      other IOCP-enabled object on Windows. Named pipes are in particular quite
      important as they're often a foundational IPC mechanism on Windows.
      
      This support is provided by exporting two new types in a `windows` module. A
      `Binding` serves as the ability to register with the actual IOCP port in an
      `Evented` implementation. Internally the `Binding` keeps track of what it
      was last associated with to implement IOCP semantics. This may one day be
      possible to make a zero-sized-type.
      
      The second type, `Overlapped`, is exported as a contract that all overlapped I/O
      operations must be executed with this particular type. This ensures that after
      an event is received from an IOCP object we know what to do with it. Essentially
      this is just a `OVERLAPPED` with a function pointer after it.
      
      Along the way this exposes the `winapi` crate as a public dependency of `mio`.
      The `OVERLAPPED_ENTRY` and `OVERLAPPED` types in `winapi` are exposed through
      the `Overlapped` type that mio itself exports.
      
      I've implemented [bindings to named pipes][bindings] and I've also got a
      proof-of-concept [process management library][tokio-process] using these
      bindings. So far it seems that this support in mio is sufficient for building up
      these applications, and it all appears to be working so far.
      
      I personally see this as a much bigger committment on the mio side of things
      than the Unix implementation. The `EventedFd` type on Unix is quite small and
      minimal, but the `Overlapped` and `binding` types on Windows are just
      pieces of a larger puzzle when dealing with overlapped operations. Questions
      about ownership of I/O objects arise along with the method of handling
      completion status notifications. For now this is essentially binding mio to
      stick to at least the same strategy for handling IOCP for the 0.6 series. A
      major version bump of mio could perhaps change these semantics, but it may be
      difficult to do so.
      
      It seems, though, that the Windows semantics are unlikely to change much in the
      near future. The overhead seems to have essentially reached its limit ("bolting
      readiness on completion") and otherwise the ownership management seems
      negligible.
      
      Closes #252
      Closes #320
      ac8b7de4
  16. 30 Aug, 2016 1 commit
  17. 26 Aug, 2016 1 commit
  18. 04 Aug, 2016 1 commit
  19. 19 Jul, 2016 2 commits
    • Alex Crichton's avatar
      Add an Events::with_capacity constructor · 4184a9d6
      Alex Crichton authored
      Should allow tuning how many events can get returned from one turn of an event
      loop, in theory at least. Somewhat related to #427 where memory tuning may
      matter in some situations.
      4184a9d6
    • Alex Crichton's avatar
      Use `ReadinessQueue` on Windows · d095d816
      Alex Crichton authored
      One of the major motivations for adding the `ReadinessQueue` was indeed using it
      on Windows! The implementation in `poll` is more battle-tested than the
      implementation in `src/sys/windows` already, so let's switch over to using it.
      
      This should also end up being more performant as well as we're able to drop a
      few locks here and there, yay!
      d095d816
  20. 18 Jul, 2016 3 commits
  21. 20 Jun, 2016 1 commit
  22. 31 May, 2016 1 commit
    • Carl Lerche's avatar
      Allow any type to implement `Evented` · 6ca6326e
      Carl Lerche authored
      This commit adds the ability to implement `Evented` and use it with a `Poll`
      instance as expected. This works by having a new readiness queue that sits
      next to the OS specific selector.
      
      Future work includes:
      
      * Implementing Timer using the new queue
      * Migrate Windows support to use the custom queue
      * Have `Poll::poll()` take `&self`
      * More documentation
      6ca6326e
  23. 28 Apr, 2016 1 commit
  24. 24 Feb, 2016 1 commit
  25. 12 Jan, 2016 1 commit
  26. 28 Dec, 2015 1 commit
  27. 23 Dec, 2015 1 commit
  28. 03 Dec, 2015 2 commits
    • Carl Lerche's avatar
      Reduce unnecessary poll wakeups · 7b73ce83
      Carl Lerche authored
      Based on #280 by luca-barbieri
      
      Currently run() results in the process waking up every second or every timer
      tick if set lower because a timeout is passed to the OS wait function.
      
      This changes the code so that run_once() still uses the timeout, but
      run() will instruct the OS to wait forever when there are no timers.
      
      The notify mechanism already uses a pipe for awakening the event loop,
      so there should be no need to use a timeout for that.
      
      This saves CPU time and battery, and is generally the correct behavior.
      
      Miscellaneous notes:
      
       * We also fix epoll because the maximum timeout supported by the Linux kernel is
         i32::MAX, not isize::MAX.
       * We fix next_tick_ms() being truncated from u64 to usize
       * It requires carllerche/nix-rust#192 to allow specifying no timeout to kevent()
       * The public API of Poll::poll is changed, but that can be avoided if desired.
      
      Closes #289
      7b73ce83
    • Carl Lerche's avatar
      Implement level triggering for windows · 7c6b41aa
      Carl Lerche authored
      The windows selector uses a linked list of currently active level-triggered
      events. When an event arrives and the socket is registered with
      level-triggered, the event is tracked in this linked list. Every call to
      select events will include all elements in this list. When an operation is
      performed on the socket such that the socket is no longer ready, the event is
      removed from the linked list.
      
      Closes #241
      7c6b41aa
  29. 01 Dec, 2015 1 commit
  30. 05 Nov, 2015 1 commit
  31. 03 Sep, 2015 1 commit
    • Alex Crichton's avatar
      windows: Remove the last HashMap in Selector · 42904eb0
      Alex Crichton authored
      This commit removes the last `HashMap` storage in the `Selector` on Windows,
      meaning that I/O scheduling and completion no longer has a `HashMap` lookup on
      either side. This was starting to show up in the profiles I was making and this
      basically erases that overhead.
      42904eb0
  32. 31 Aug, 2015 2 commits
    • Alex Crichton's avatar
      windows: Pool buffers on the selector · 13d5fc9e
      Alex Crichton authored
      This adds a cache of buffers to be stored locally on the selector for new
      requests to use for both reads and writes. The cache has a maximum size of the
      number of buffers it can store and new buffers are allocated if the cache is
      empty at the time.
      
      Closes #245
      13d5fc9e
    • Alex Crichton's avatar
      windows: Remove Selector::io · 98f12817
      Alex Crichton authored
      This commit removes the internal hash map from Windows' Selector implementation
      keeping track of what to do after any I/O completes. The "completion callback"
      is now stored right after the OVERLAPPED structure in memory, and unsafe casting
      is done to get back to the original `Arc<T>` and process the I/O event.
      
      Currently this involves vendoring a small copy of `Arc<T>` to ensure that the
      memory layout is guaranteed, but this guarantee could in theory be added to the
      standard library one day.
      
      Closes #243
      98f12817
  33. 25 Aug, 2015 1 commit
    • Alex Crichton's avatar
      Preliminary Windows TCP/UDP support · c45b0282
      Alex Crichton authored
      These commits add preliminary support for the TCP/UDP API of mio, built on top
      of IOCP using some raw Rust bindings plus some networking extensions as the
      foundational support. This support is definitely still experimental as there are
      likely to be a number of bugs and kinks to work out.
      
      I haven't yet done much benchmarking as there are still a number of places I
      would like to improve the implementation in terms of performance. I've also been
      focusing on getting "hello world" and the in-tree tests working ASAP to start
      getting some broader usage and feedback. High level docs are available in the
      src/sys/windows/mod.rs file and the TCP/UDP implementations are quite similar in
      terms of how they're implemented.
      
      Not many new tests were added, but all tests (other than those using unix
      sockets) are passing on Windows and an appveyor.yml file was also added to
      enable AppVeyor CI support to ensure this doesn't regress.
      
      cc #155
      c45b0282