Previous version had too much state: `cnt`, `steals`, `port_dropped`
fields, and it's too hard to consistently update all of them during
upgrade.  I tried to fix issue rust-lang#39364, but there are too many corner
cases.  In this version all of these fields removed, and shared
state is basically managed by two fields: `queue` and `to_wait`.

`to_wake` field now stores both `SignalToken` and "disconnected"
flag.

All tests still pass, and bug rust-lang#39364 no longer reproduces.

Patch includes a couple of stress tests.

This version should have the same performance characteristics,
because roughly the same number of atomics and wait/notify operations
involved.

It will conditionally panic due to this issue: rust-lang/rust#39364
The issue is not fixed yet, so I try to use alternative ways (e.g.
try_recv & sleep).
It will cause some performance penalty in theory, but not noticable by
human(for now).

The recv_timeout function panics due to this issue: rust-lang/rust#39364
Using try_recv and a short sleep in case the channel is empty should be
suitable alternative for our use case.

cf. rust-lang/rust#39364

Also take this opportunity to centralize the expect threads.

On Apple Silicon, we were hitting a concurrency error that manifest
with recv() panicking like this:

thread '<unnamed>' panicked at 'internal error: entered unreachable
code'

Seems to be a known issue
rust-lang/rust#39364

Follow the recommendation on the thread, and switch from mpsc (which
seems its going to be retired) to crossbeam-channel.

Signed-off-by: Sergio Lopez <[email protected]>

On Apple Silicon, we were hitting a concurrency error that manifest
with recv() panicking like this:

thread '<unnamed>' panicked at 'internal error: entered unreachable
code'

Seems to be a known issue
rust-lang/rust#39364

Follow the recommendation on the thread, and switch from mpsc (which
seems its going to be retired) to crossbeam-channel.

Signed-off-by: Sergio Lopez <[email protected]>

On Apple Silicon, we were hitting a concurrency error that manifest
with recv() panicking like this:

thread '<unnamed>' panicked at 'internal error: entered unreachable
code'

Seems to be a known issue
rust-lang/rust#39364

Follow the recommendation on the thread, and switch from mpsc (which
seems its going to be retired) to crossbeam-channel.

Signed-off-by: Sergio Lopez <[email protected]>

On Apple Silicon, we were hitting a concurrency error that manifest
with recv() panicking like this:

thread '<unnamed>' panicked at 'internal error: entered unreachable
code'

Seems to be a known issue
rust-lang/rust#39364

Follow the recommendation on the thread, and switch from mpsc (which
seems its going to be retired) to crossbeam-channel.

Signed-off-by: Sergio Lopez <[email protected]>

On Apple Silicon, we were hitting a concurrency error that manifest
with recv() panicking like this:

thread '<unnamed>' panicked at 'internal error: entered unreachable
code'

Seems to be a known issue
rust-lang/rust#39364

Follow the recommendation on the thread, and switch from mpsc (which
seems its going to be retired) to crossbeam-channel.

Signed-off-by: Sergio Lopez <[email protected]>

v8.5.2
Bugfixes
 - Fix --owner option value parsing, see #1163 and #1164 (@tmccombs)

v8.5.1
Bugfixes
 - Fix --threads/-j option value parsing, see #1160 and #1162 (@sharkdp)

v8.5.0
Features
 --type executable/-t now works on Windows, see #1051 and #1061 (@tavianator)

Bugfixes
 - Fixed differences between piped / non-piped output. This changes fds
   behavior back to what we had before 8.3.0, i.e. there will be no leading
   ./ prefixes, unless --exec/-x, --exec-batch/-X, or --print0/-0 are used.
   --strip-cwd-prefix can be used to strip that prefix in those cases.
   See #1046, #1115, and #1121 (@tavianator)
 - fd could previously crash with a panic due to a race condition in Rusts
   standard library (see rust-lang/rust#39364). This has been fixed by switching
   to a different message passing implementation, see #1060 and #1146
   (@tavianator)
 - fds memory usage will not grow unboundedly on huge directory trees,
   see #1146 (@tavianator)
 - fd returns an error when current working directory does not exist while a
   search path is specified, see #1072 (@vijfhoek)
 - Improved "command not found" error message, see #1083 and #1109 (@themkat)
 - Preserve command exit codes when using --exec-batch, see #1136 and #1137
   (@amesgen)

Changes
 - No leading ./ prefix for non-interactive results, see above.
 - fd now colorizes paths in parallel, significantly improving performance,
   see #1148 (@tavianator)
 - fd can now avoid stat syscalls even when colorizing paths, as long as the
   color scheme doesn't require metadata, see #1148 (@tavianator)
 - The statically linked musl versions of fd now use jmalloc, leading to a
   significant performance improvement, see #1062 (@tavianator)

Other
 - Added link back to GitHub in man page and --help text, see #1086
   (@scottchiefbaker)
 - Major update in how fd handles command line options internally,
   see #1067 (@tmccombs)

v8.4.0
Features
 - Support multiple --exec <cmd> instances, see #406 and #960 (@tmccombs)

Bugfixes
 - "Argument list too long" errors can not appear anymore when using
   --exec-batch/-X, as the command invocations are automatically batched at the
   maximum possible size, even if --batch-size is not given. See #410 and
   #1020 (@tavianator)

Changes
 - Directories are now printed with an additional path separator at the end:
   foo/bar/, see #436 and #812 (@yyogo)
 - The -u flag was changed to be equivalent to -HI (previously, a single -u was
   only equivalent to -I). Additional -u flags are still allowed, but ignored.
   See #840 and #986 (@jacksontheel)

Other
 - Added installation instructions for RHEL8, see #989 (@ethsol)

Merge crossbeam-channel into `std::sync::mpsc`

This PR imports the [`crossbeam-channel`](https://github.com/crossbeam-rs/crossbeam/tree/master/crossbeam-channel#crossbeam-channel) crate into the standard library as a private module, `sync::mpmc`. `sync::mpsc` is now implemented as a thin wrapper around `sync::mpmc`. The primary purpose of this PR is to resolve rust-lang/rust#39364. The public API intentionally remains the same.

The reason rust-lang/rust#39364 has not been fixed in over 5 years is that the current channel is *incredibly* complex. It was written many years ago and has sat mostly untouched since. `crossbeam-channel` has become the most popular alternative on crates.io, amassing over 30 million downloads. While crossbeam's channel is also complex, like all fast concurrent data structures, it avoids some of the major issues with the current implementation around dynamic flavor upgrades. The new implementation decides on the datastructure to be used when the channel is created, and the channel retains that structure until it is dropped.

Replacing `sync::mpsc` with a simpler, less performant implementation has been discussed as an alternative. However, Rust touts itself as enabling *fearless concurrency*, and having the standard library feature a subpar implementation of a core concurrency primitive doesn't feel right. The argument is that slower is better than broken, but this PR shows that we can do better.

As mentioned before, the primary purpose of this PR is to fix rust-lang/rust#39364, and so the public API intentionally remains the same. *After* that problem is fixed, the fact that `sync::mpmc` now exists makes it easier to fix the primary limitation of `mpsc`, the fact that it only supports a single consumer. spmc and mpmc are two other common concurrency patterns, and this change enables a path to deprecating `mpsc` and exposing a general `sync::channel` module that supports multiple consumers. It also implements other useful methods such as `send_timeout`. That said, exposing MPMC and other new functionality is mostly out of scope for this PR, and it would be helpful if discussion stays on topic :)

For what it's worth, the new implementation has also been shown to be more performant in [some basic benchmarks](https://github.com/crossbeam-rs/crossbeam/tree/master/crossbeam-channel/benchmarks#results).

cc `@taiki-e`

r? rust-lang/libs

Merge crossbeam-channel into `std::sync::mpsc`

This PR imports the [`crossbeam-channel`](https://github.com/crossbeam-rs/crossbeam/tree/master/crossbeam-channel#crossbeam-channel) crate into the standard library as a private module, `sync::mpmc`. `sync::mpsc` is now implemented as a thin wrapper around `sync::mpmc`. The primary purpose of this PR is to resolve rust-lang/rust#39364. The public API intentionally remains the same.

The reason rust-lang/rust#39364 has not been fixed in over 5 years is that the current channel is *incredibly* complex. It was written many years ago and has sat mostly untouched since. `crossbeam-channel` has become the most popular alternative on crates.io, amassing over 30 million downloads. While crossbeam's channel is also complex, like all fast concurrent data structures, it avoids some of the major issues with the current implementation around dynamic flavor upgrades. The new implementation decides on the datastructure to be used when the channel is created, and the channel retains that structure until it is dropped.

Replacing `sync::mpsc` with a simpler, less performant implementation has been discussed as an alternative. However, Rust touts itself as enabling *fearless concurrency*, and having the standard library feature a subpar implementation of a core concurrency primitive doesn't feel right. The argument is that slower is better than broken, but this PR shows that we can do better.

As mentioned before, the primary purpose of this PR is to fix rust-lang/rust#39364, and so the public API intentionally remains the same. *After* that problem is fixed, the fact that `sync::mpmc` now exists makes it easier to fix the primary limitation of `mpsc`, the fact that it only supports a single consumer. spmc and mpmc are two other common concurrency patterns, and this change enables a path to deprecating `mpsc` and exposing a general `sync::channel` module that supports multiple consumers. It also implements other useful methods such as `send_timeout`. That said, exposing MPMC and other new functionality is mostly out of scope for this PR, and it would be helpful if discussion stays on topic :)

For what it's worth, the new implementation has also been shown to be more performant in [some basic benchmarks](https://github.com/crossbeam-rs/crossbeam/tree/master/crossbeam-channel/benchmarks#results).

cc `@taiki-e`

r? rust-lang/libs

see rust-lang/rust#39364

We'll need to ask the poller thread another thing besides to shut down,
so it's cleaner to start using proper messages.

The mpsc channel in the std lib was buggy for awhile but since they
merged crossbeam and are using this behind the hood now it should be
fine starting with Rust 1.67. That's (slightly) higher than our MSRV but
it's what we use for releases so that's reasonable. See
rust-lang/rust#39364 for details.

We'll need to ask the poller thread another thing besides to shut down,
so it's cleaner to start using proper messages.

The mpsc channel in the std lib was buggy for awhile but since they
merged crossbeam and are using this behind the hood now it should be
fine starting with Rust 1.67. That's (slightly) higher than our MSRV but
it's what we use for releases so that's reasonable. See
rust-lang/rust#39364 for details.

We'll need to ask the poller thread another thing besides to shut down,
so it's cleaner to start using proper messages.

The mpsc channel in the std lib was buggy for awhile but since they
merged crossbeam and are using this behind the hood now it should be
fine starting with Rust 1.67. That's (slightly) higher than our MSRV but
it's what we use for releases so that's reasonable. See
rust-lang/rust#39364 for details.

Merge crossbeam-channel into `std::sync::mpsc`

This PR imports the [`crossbeam-channel`](https://github.com/crossbeam-rs/crossbeam/tree/master/crossbeam-channel#crossbeam-channel) crate into the standard library as a private module, `sync::mpmc`. `sync::mpsc` is now implemented as a thin wrapper around `sync::mpmc`. The primary purpose of this PR is to resolve rust-lang/rust#39364. The public API intentionally remains the same.

The reason rust-lang/rust#39364 has not been fixed in over 5 years is that the current channel is *incredibly* complex. It was written many years ago and has sat mostly untouched since. `crossbeam-channel` has become the most popular alternative on crates.io, amassing over 30 million downloads. While crossbeam's channel is also complex, like all fast concurrent data structures, it avoids some of the major issues with the current implementation around dynamic flavor upgrades. The new implementation decides on the datastructure to be used when the channel is created, and the channel retains that structure until it is dropped.

Replacing `sync::mpsc` with a simpler, less performant implementation has been discussed as an alternative. However, Rust touts itself as enabling *fearless concurrency*, and having the standard library feature a subpar implementation of a core concurrency primitive doesn't feel right. The argument is that slower is better than broken, but this PR shows that we can do better.

As mentioned before, the primary purpose of this PR is to fix rust-lang/rust#39364, and so the public API intentionally remains the same. *After* that problem is fixed, the fact that `sync::mpmc` now exists makes it easier to fix the primary limitation of `mpsc`, the fact that it only supports a single consumer. spmc and mpmc are two other common concurrency patterns, and this change enables a path to deprecating `mpsc` and exposing a general `sync::channel` module that supports multiple consumers. It also implements other useful methods such as `send_timeout`. That said, exposing MPMC and other new functionality is mostly out of scope for this PR, and it would be helpful if discussion stays on topic :)

For what it's worth, the new implementation has also been shown to be more performant in [some basic benchmarks](https://github.com/crossbeam-rs/crossbeam/tree/master/crossbeam-channel/benchmarks#results).

cc `@taiki-e`

r? rust-lang/libs

Merge crossbeam-channel into `std::sync::mpsc`

This PR imports the [`crossbeam-channel`](https://github.com/crossbeam-rs/crossbeam/tree/master/crossbeam-channel#crossbeam-channel) crate into the standard library as a private module, `sync::mpmc`. `sync::mpsc` is now implemented as a thin wrapper around `sync::mpmc`. The primary purpose of this PR is to resolve rust-lang/rust#39364. The public API intentionally remains the same.

The reason rust-lang/rust#39364 has not been fixed in over 5 years is that the current channel is *incredibly* complex. It was written many years ago and has sat mostly untouched since. `crossbeam-channel` has become the most popular alternative on crates.io, amassing over 30 million downloads. While crossbeam's channel is also complex, like all fast concurrent data structures, it avoids some of the major issues with the current implementation around dynamic flavor upgrades. The new implementation decides on the datastructure to be used when the channel is created, and the channel retains that structure until it is dropped.

Replacing `sync::mpsc` with a simpler, less performant implementation has been discussed as an alternative. However, Rust touts itself as enabling *fearless concurrency*, and having the standard library feature a subpar implementation of a core concurrency primitive doesn't feel right. The argument is that slower is better than broken, but this PR shows that we can do better.

As mentioned before, the primary purpose of this PR is to fix rust-lang/rust#39364, and so the public API intentionally remains the same. *After* that problem is fixed, the fact that `sync::mpmc` now exists makes it easier to fix the primary limitation of `mpsc`, the fact that it only supports a single consumer. spmc and mpmc are two other common concurrency patterns, and this change enables a path to deprecating `mpsc` and exposing a general `sync::channel` module that supports multiple consumers. It also implements other useful methods such as `send_timeout`. That said, exposing MPMC and other new functionality is mostly out of scope for this PR, and it would be helpful if discussion stays on topic :)

For what it's worth, the new implementation has also been shown to be more performant in [some basic benchmarks](https://github.com/crossbeam-rs/crossbeam/tree/master/crossbeam-channel/benchmarks#results).

cc `@taiki-e`

r? rust-lang/libs