## 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>
- `tokio::run` checks Enter before creating a new threadpool and
spawning the main future.
- `Runtime::block_on` now checks Enter
- `Runtime::block_on_all` now checks Enter
<!--
Thank you for your Pull Request. Please provide a description above and review
the requirements below.
Bug fixes and new features should include tests.
Contributors guide: https://github.com/tokio-rs/tokio/blob/master/CONTRIBUTING.md
-->
## Motivation
Now that each worker thread drives its own reactor, reactors have to be driven until the threadpool shuts down. We mustn't use the `keep_alive` setting to shut down a worker thread if it doesn't receive an event from the reactor for a certain duration of time.
<!--
Explain the context and why you're making that change. What is the problem
you're trying to solve? In some cases there is not a problem and this can be
thought of as being the motivation for your change.
-->
## Solution
Just ignore the `keep_alive` setting when parking in `Worker::sleep`.
<!--
Summarize the solution and provide any necessary context needed to understand
the code change.
-->
Fixes: #681
## Motivation
Currently, a potential panic exists in `LengthDelimitedCodec::encode`.
Writing the length field to the `dst` buffer can exceed the buffer
capacity, as `BufMut::put_uint_{le,be}` doesn't reserve more capacity.
## Solution
This branch adds a call to `dst.reserve` to ensure that there's
sufficient remaining buffer capacity to hold the length field and
the frame, prior to writing the length field. Previously, capacity
was only reserved later in the function, when writing the frame
to the buffer, and we never reserved capacity for the length field.
I've also added a test that reproduces the issue. The test panics on
master, but passes after making this change.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
* io: ensure ReadHalf/WriteHalf do not return WouldBlock directly
These facades were passing back WouldBlock when the internal BiLock
couldn't be acquired, which does not fit the intended behavior.
Signed-off-by: Toby Lawrence <toby@nuclearfurnace.com>
* io: pull from the local crate, not crates.io
## Motivation
Currently, there is a potential denial of service vulnerability in the
`lines` codec. Since there is no bound on the buffer that holds data
before it is split into a new line, an attacker could send an unbounded
amount of data without sending a `\n` character.
## Solution
This branch adds a `new_with_max_length` constructor for `LinesCodec`
that configures a limit on the maximum number of bytes per line. When
the limit is reached, the the overly long line will be discarded (in
`max_length`-sized increments until a newline character or the end of the
buffer is reached. It was also necessary to add some special-case logic
to avoid creating an empty line when the length limit is reached at the
character immediately _before_ a `\n` character.
Additionally, this branch adds new tests for this function, including a
test for changing the line limit in-flight.
## Notes
This branch makes the following changes from my original PR with
this change (#590):
- The whole too-long line is discarded at once in the first call to `decode`
that encounters it.
- Only one error is emitted per too-long line.
- Made all the changes requested by @carllerche in
https://github.com/tokio-rs/tokio/pull/590#issuecomment-420735023Fixes: #186
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Currently, the `RUST_BACKTRACE` environment variable is set to `1` on
Travis CI builds:
0ca973a7eb/.travis.yml (L49)
However, it's not set on AppVeyor. This can make debugging
Windows-specific CI failures challenging for developers on other
operating systems.
## Solution
This branch sets `RUST_BACKTRACE=1` on AppVeyor.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
