summary refs log tree commit diff
path: root/library/std/src/sync/mpmc
AgeCommit message (Collapse)AuthorLines
2024-11-12Rollup merge of #132869 - ↵Matthias Krüger-0/+2
lolbinarycat:library-fix-too_long_first_doc_paragraph, r=tgross35 split up the first paragraph of doc comments for better summaries used `./x clippy -Aclippy::all '-Wclippy::too_long_first_doc_paragraph' library/core library/alloc` to find these issues.
2024-11-10split up the first paragraph of doc comments for better summariesbinarycat-0/+2
2024-11-07Initialize channel `Block`s directly on the heapJosh Stone-4/+4
The channel's `Block::new` was causing a stack overflow because it held 32 item slots, instantiated on the stack before moving to `Box::new`. The 32x multiplier made modestly-large item sizes untenable. That block is now initialized directly on the heap. Fixes #102246
2024-10-25library: consistently use American spelling for 'behavior'Ralf Jung-1/+1
2024-10-02mpmc doctest: make sure main thread waits for child threadsRalf Jung-22/+24
2024-09-30Add multi-producer, multi-consumer channel (mpmc)Obei Sideg-47/+1721
2024-09-25Use `&raw` in the standard libraryJosh Stone-10/+2
Since the stabilization in #127679 has reached stage0, 1.82-beta, we can start using `&raw` freely, and even the soft-deprecated `ptr::addr_of!` and `ptr::addr_of_mut!` can stop allowing the unstable feature. I intentionally did not change any documentation or tests, but the rest of those macro uses are all now using `&raw const` or `&raw mut` in the standard library.
2024-09-22Reformat using the new identifier sorting from rustfmtMichael Goulet-3/+3
2024-08-31Fixed some typos in the standard library documentation/commentsranger-ross-1/+1
2024-07-29Reformat `use` declarations.Nicholas Nethercote-11/+4
The previous commit updated `rustfmt.toml` appropriately. This commit is the outcome of running `x fmt --all` with the new formatting options.
2024-07-14std: Unsafe-wrap std::syncJubilee Young-36/+48
2024-02-29fix typosIbraheem Ahmed-3/+3
Co-authored-by: Ralf Jung <post@ralfj.de>
2024-02-29document potential memory leak in unbounded channelIbraheem Ahmed-0/+3
2024-02-26fix race between block initialization and receiver disconnectionIbraheem Ahmed-2/+2
2024-02-24library: use `addr_of!`Pavel Grigorenko-2/+6
2023-07-19avoid tls access while iterating through mpsc thread entriesIbraheem Ahmed-20/+26
2023-07-18support for mips32r6 as a target_arch valuechenx97-0/+2
2023-07-18support for mips64r6 as a target_arch valuechenx97-0/+2
2023-05-03Remove unnecessary Send boundGil Shoshan-1/+1
2023-04-08sync::mpsc: synchronize receiver disconnect with initializationPetros 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-14std: leak remaining messages in bounded channel if message destructor panicsjoboet-66/+42
2023-02-26std: disconnect senders before discarding messagesjoboet-4/+5
2023-02-17std: drop all messages in bounded channel when destroying the last receiverjoboet-27/+109
2023-01-14remove optimistic spinning from `mpsc::SyncSender`Ibraheem Ahmed-23/+7
2023-01-11rework and document backoff behavior of `sync::mpsc`Ibraheem Ahmed-31/+30
2023-01-10add `SyncSender::send_timeout` testIbraheem Ahmed-1/+1
2023-01-10fix `SyncSender` spinning behaviorIbraheem Ahmed-1/+1
2022-12-28Rollup 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-05fix dupe word typosRageking8-1/+1
2022-11-22rustdoc: Fix backoff doc to match implementationJonas Spinner-1/+1
2022-11-12avoid calling `thread::current` in channel destructorIbraheem Ahmed-13/+11
2022-11-09tidyIbraheem Ahmed-5/+4
2022-11-09spin less in `mpsc::SyncSender::send`Ibraheem Ahmed-1/+1
2022-11-09remove extra spinning from `mpsc` parkerIbraheem Ahmed-15/+0
2022-11-09`sync::mpsc`: quadratic backoffIbraheem Ahmed-2/+3
2022-11-09`sync::mpsc`: reload state after spinning on CAS failureIbraheem Ahmed-8/+8
2022-11-09remove extra spinning from `mpsc::Receiver::recv`Ibraheem Ahmed-26/+6
2022-11-09initial port of crossbeam-channelIbraheem Ahmed-0/+2693