## Motivation
`tokio_threadpool::ThreadPool::spawn` has no return value.
## Solution
Add `ThreadPool::spawn_handle` which calls
`futures::sync::oneshot::spawn` to return a future represents the return
value.
This also bumps a number of sub crates:
* tokio-executor (0.1.3)
* tokio-io (0.1.8)
* tokio-reactor (0.1.4)
* tokio-threadpool (0.1.6)
* tokio-timer (0.2.6)
* tokio-udp (0.1.2)
The futures 0.2 crate is not intended for widespread usage. Also, the
futures team is exploring the compat shim route.
If futures 0.3 support is added to Tokio 0.1, then a different
integration route will be explored, making the current code unhelpful.
* Normalize links to docs.rs/CRATE/M.N/...
docs.rs is smart enough to show docs for the latest M.N.P release when
M.N is used in the link. For example:
https://docs.rs/mio/0.6/mio/struct.Poll.html
..will show mio 0.6.14 and later docs. While using the `M.N.*`
(ASTERISK) syntax also works, `M.N` is the more common usage, so
standarize a few existing links to that format.
* Fix missing or malformed rustdoc links
* executor lib rustdoc minor format change
* Promote tokio-threadpool crate level comments to rustdoc
* Replace hidden tokio::executor::thread_pool docs with deprecation note
* Fix typo/simplify util module rustdoc
* Reuse some tokio::executor::thread_pool rustdoc for the crate
Relates to #421
The thread pool optimizes cases where a task currently running on the
pool spawns a new future. However, the optimization did not factor in
cases where two thread pools interacted.
This patch fixes the optimization and includes a test.
Fixes#342
This patch adds a new crate: tokio-fs. This crate provides a wrapper
around `std` functionality that can only be performed using blocking
operations. This primarily includes filesystem operations, but it also
includes standard input, output, and error access as these streams
cannot be safely switched to non-blocking mode in a portable way.
These wrappers call the `std` functions from within a `blocking`
annotation which allows the runtime to compensate for the fact that the
thread will potentially remain blocked in a system call.
Currently, the state of the futures2 integration is pretty broken. This
patch removes the feature flag, preventing users from trying to use it.
In the future, it can be brought back when the implementation is fixed.
This patch adds a `blocking` to `tokio-threadpool`. This function serves
as a way to annotate sections of code that will perform blocking
operations. This informs the thread pool that an additional thread needs
to be spawned to replace the current thread, which will no longer be
able to process the work queue.
Replaces homegrown Arc with std Arc
Is this safer? Unknown. At least we don't have to maintain an arc
implementation anymore. This will also make it easier to filter out tsan
false positives.
Also split task/mod.rs into multiple files.
This patch integrate the new timer implementation with the runtime by
initializing a timer per worker thread. This allows minimizing the
amount of synchronization needed for using timers.
* Allow customizing the threadpool's parker
This patch allows the user of threadpool to customize how the worker
threads park themselves. This allows custom parking logic to be
injected. For example, this allows embedding a timer on each worker
thread.
* Call `park` instance every so often.
Since the `park` is now customizable, it might have logic that must be
called every so often. For example, a timer might have timeouts that it
must expire.
Currently, if a worker is very busy, it won't call into the `park`
instance. This patch changes this so that after every 32 task
invocations, `park` is called with a duration of zero.
* Fix races.
This mostly pulls in changes from rust-lang-nursery/futures-rs#881, but
also updates Registration to be a bit more obvious as to what is going
on.
* Reduce spurious wakeups caused by Reactor
This patch adds an ABA guard on token values before registering them
with Mio. This allows catching token reuse and avoid the notification.
This is needed for OS X as the notification is used to determine that a
TCP connect has completed. A spurious notification can potentially cause
write failures.
