rust - https://github.com/rust-lang/rust

Age	Commit message (Collapse)	Author	Lines
2023-07-19	avoid tls access while iterating through mpsc thread entries	Ibraheem Ahmed	-20/+26

2023-07-18	support for mips32r6 as a target_arch value	chenx97	-0/+2

2023-07-18	support for mips64r6 as a target_arch value	chenx97	-0/+2

2023-05-03	Remove unnecessary Send bound	Gil Shoshan	-1/+1

2023-04-08	sync::mpsc: synchronize receiver disconnect with initialization	Petros Angelatos	-0/+12
	Receiver disconnection relies on the incorrect assumption that `head.index != tail.index` implies that the channel is initialized (i.e `head.block` and `tail.block` point to allocated blocks). However, it can happen that `head.index != tail.index` and `head.block == null` at the same time which leads to a segfault when a channel is dropped in that state. This can happen because initialization is performed in two steps. First, the tail block is allocated and the `tail.block` is set. If that is successful `head.block` is set to the same pointer. Importantly, initialization is skipped if `tail.block` is not null. Therefore we can have the following situation: 1. Thread A starts to send the first value of the channel, observes that `tail.block` is null and begins initialization. It sets `tail.block` to point to a newly allocated block and then gets preempted. `head.block` is still null at this point. 2. Thread B starts to send the second value of the channel, observes that `tail.block` is not null and proceeds with writing its value in the allocated tail block and sets `tail.index` to 1. 3. Thread B drops the receiver of the channel which observes that `head.index != tail.index` (0 and 1 respectively), therefore there must be messages to drop. It starts traversing the linked list from `head.block` which is still a null pointer, leading to a segfault. This PR fixes this problem by waiting for initialization to complete when `head.index != tail.index` and the `head.block` is still null. A similar check exists in `start_recv` for similar reasons. Fixes #110001 Signed-off-by: Petros Angelatos <petrosagg@gmail.com>
2023-03-14	std: leak remaining messages in bounded channel if message destructor panics	joboet	-66/+42

2023-02-26	std: disconnect senders before discarding messages	joboet	-4/+5

2023-02-17	std: drop all messages in bounded channel when destroying the last receiver	joboet	-27/+109

2023-01-14	remove optimistic spinning from `mpsc::SyncSender`	Ibraheem Ahmed	-23/+7

2023-01-11	rework and document backoff behavior of `sync::mpsc`	Ibraheem Ahmed	-31/+30

2023-01-10	add `SyncSender::send_timeout` test	Ibraheem Ahmed	-1/+1

2023-01-10	fix `SyncSender` spinning behavior	Ibraheem Ahmed	-1/+1

2022-12-28	Rollup merge of #104708 - ↵	fee1-dead	-1/+1
	jonasspinner:fix-backoff-doc-to-match-implementation, r=compiler-errors Fix backoff doc to match implementation The commit 8dddb2294310ad3e8ce0b2af735a702ad72a9a99 in the crossbeam-channel PR (#93563) changed the backoff strategy to be quadratic instead of exponential. This updates the doc to prevent confusion.
2022-12-05	fix dupe word typos	Rageking8	-1/+1

2022-11-22	rustdoc: Fix backoff doc to match implementation	Jonas Spinner	-1/+1

2022-11-12	avoid calling `thread::current` in channel destructor	Ibraheem Ahmed	-13/+11

2022-11-09	tidy	Ibraheem Ahmed	-5/+4

2022-11-09	spin less in `mpsc::SyncSender::send`	Ibraheem Ahmed	-1/+1

2022-11-09	remove extra spinning from `mpsc` parker	Ibraheem Ahmed	-15/+0

2022-11-09	`sync::mpsc`: quadratic backoff	Ibraheem Ahmed	-2/+3

2022-11-09	`sync::mpsc`: reload state after spinning on CAS failure	Ibraheem Ahmed	-8/+8

2022-11-09	remove extra spinning from `mpsc::Receiver::recv`	Ibraheem Ahmed	-26/+6

2022-11-09	initial port of crossbeam-channel	Ibraheem Ahmed	-0/+2693