`inner` is a fitting name for variables of type named `Inner`, but in other cases I find them confusing - sometimes `inner` refers to a `Pool`, sometimes to a `Sender`. I renamed a bunch of variables named `inner` to be more descriptive.
This PR is the first step in an effort of splitting https://github.com/tokio-rs/tokio/pull/722#issuecomment-439552671 into multiple PRs.
When spawning using `Handle` while on the executor, tasks were being
double counted. This prevented the number of active tasks to reach zero,
thus preventing the executor from shutting down.
This changes `spawn` to check if being called from the executor
**before** incrementing the number of active tasks.
Fixes#760
Should hopefully fix the underlying bug that was causing tokio-tls tests to occasionally fail on Windows.
Signed-off-by: Toby Lawrence <toby@nuclearfurnace.com>
* async-await: fix README example dependencies
As per commit "async-await: track nightly changes (#661)" ( commit
2f690d30bc061a8595744e34fde371882b676a86)
> The `tokio-async-await` crate is no longer a facade. Instead, the
> `tokio` crate provides a feature flag to enable async/await support.
Ensure the example in the async-await README file also works by
correctly declaring this updated dependency
* async-await: remove unnecessary 'edition' declaration from README
As the "edition" feature was stabilized in rust v1.30 and async-await
specifies that the nightly toolchain must be used, remove the use of the
"edition" feature gate since it is enabled by default.
* Minimize allocation needed for channels
* Use a newtype for signal ids
* We can just cast the raw pointer to a `usize` and still perform a
simple identity check, without incurring any implications of storing a
raw pointer (e.g. previously Signal was !Sync and had an unsafe impl of
Send, and now it is naturally Sync+Send)
* Broadcast with `try_send` instead of `start_send`
The `Stream::start_send` method uses backpressure and schedules the
current task to be notified whenever the channel has additional room,
which means we'll generate a lot of unnecessary wakeups whenever a
channel gets full
By changing to `try_send` and handling any errors, we ensure the
Driver's task won't get woken up when a Signal finally consumes its
notification, since we're coalescing things anyway
* udp: add `into_parts` to `RecvDgram`
If `RecvDgram` can not be driven to completion it may become necessary to get back the `UdpSocket` it contains which is currently not possible.
This adds`into_parts` to get the socket as well as the buffer back. Both methods consume `RecvDgram`.
Note that after the future has completed, `into_parts` must not be used, or else a panic will happen.
## Motivation
tokio depends on an out of date version of crossbeam-utils, which results in multiple versions of that package being linked in binaries which use other popular libraries.
## Solution
Bump the version; there's no API changes and tests still pass.
* rt: fix `Runtime::reactor()` as used by tokio-core
Up until Tokio v0.1.11, the handle returned by `Runtime::reactor()`
pointed to a reactor instance running in a background thread. The thread
was eagerly spawned.
As of v0.1.12, a reactor instance is created per runtime worker thread.
`Runtime::reactor()` was deprecated and updated to point to the reactor
for one of the worker threads.
A problem occurs when attempting to use the reactor before spawning a
task. Worker threads are spawned lazily, which means that the reactor
referenced by `Runtime::reactor()` is not yet running.
This patch changes `Runtime::reactor` back to a dedicated reactor
running on a background thread. However, the background thread is now
spawned lazily when the deprecated function is first called.
Fixes#720
* Fix comment
Co-Authored-By: carllerche <me@carllerche.com>
