The tcp-accept-stress, despite the previous modifications, is still deadlocking
on the osx buildbots. When building/testing/running repeatedly locally, it was
discovered that the test would often fail with TcpStream::connect returning the
error `address not available`.
This test opens up quite a large number of sockets, and it looks like by default
osx isn't the speediest at recycling those sockets for further use.
The test has been modified (and verified) to not deadlock in this error case,
and the test is not just officially ignored on OSX (with no FIXME). I believe
that we'll get good coverage of the relevant code on the linux builders, so this
isn't so much of a loss.
At the same time I turned down the stress parameters to hopefully lighten the
socket load on other platforms.
Not sure if this is addressing the root cause or just patching up a symptom. Also not sure if I should be adding a diagnostic code for this.
Fixes#16750Fixes#15812
Enables any macros using `MacExpr` to be treated as patterns when
they produce a literal in the form `ExprLit` (e.g. `stringify!` or `line!`).
Fixes#16876.
These are the additions to liblibc required for raw/custom socket support. I've broken this into a separate pull request due to the upcoming I/O overhaul (was originally part of pull #15741).
cc @alexcrichton.
The tcp-accept-stress, despite the previous modifications, is still deadlocking
on the osx buildbots. When building/testing/running repeatedly locally, it was
discovered that the test would often fail with TcpStream::connect returning the
error `address not available`.
This test opens up quite a large number of sockets, and it looks like by default
osx isn't the speediest at recycling those sockets for further use.
The test has been modified (and verified) to not deadlock in this error case,
and the test is not just officially ignored on OSX (with no FIXME). I believe
that we'll get good coverage of the relevant code on the linux builders, so this
isn't so much of a loss.
At the same time I turned down the stress parameters to hopefully lighten the
socket load on other platforms.
It was previously asserted that each thread received at least one connection,
but this is not guaranteed to always be the case due to scheduling. This test
also deadlocked on failure due to a lingering reference to the sending half of
the channel, so that reference is now also eagerly dropped so the test can fail
properly if something bad happens.
Closes#16872
It was previously asserted that each thread received at least one connection,
but this is not guaranteed to always be the case due to scheduling. This test
also deadlocked on failure due to a lingering reference to the sending half of
the channel, so that reference is now also eagerly dropped so the test can fail
properly if something bad happens.
Closes#16872
This changes the `Add` and `Sub` implementations for `Timespec` introduced in #16573 to use `Duration` as the time span type instead of `Timespec` itself, as [suggested](https://github.com/rust-lang/rust/pull/16573#issuecomment-52593408) by @sfackler.
This depends on #16626, because is uses `Duration::seconds(i64)`, whereas currently `Duration::seconds` takes an `i32`.
